views:

26

answers:

1
+1  Q: 

EJB3 RMI client

Hello Everybody!

I'm currently working with on a fat client application using a self written RMI server (10 years ago). The server sends EJB1.1/2.0 beans to the client who has full access to these remote objects. After commiting a transaction, all dirty beans are persisted by the server.

The plan is to replace the server by a JBoss5 & EJB3 without (massively) changing the client app (roughly 10000 class files). A typical client snip would be

UserTransaction tx = ClientCtxManager.getUserTransaction();
tx.begin();
DummyClassHome dummyHome = (DummyClassHome)lookup(DummyClassHome.class.getName());
DummyClass dummy = dummyHome.findByPrimaryKey(1234);
dummy.setValue("Hello World");
tx.commmit();

-> dummy persisted on the server.

On JBoss I use a stateless session bean for executing findByPrimaryKey. In this finder I lookup a RemoteInterface of a stateful session bean, which I would like to use to carry the entity to the client. Because of Serialization/Deserialization the entity looses the connection to the session which would be vital for commiting changes.

// DummyHome implementation
public MyClass findByPrimaryKey(BigDecimal pk)
{
Session s = HibernateUtil.getSessionFactory().getCurrentSession();
MyClassEntity temp = (MyClassEntity)s.get(MyClassEntity.class, (BigDecimal)pk);
// session.contains(temp) delivers true  
MyClassRemote remote = (MyClassRemote)InitialContextFactory.getInitialContext().lookup("DemoEAR/MyClassBean/remote");
remote.setENTITY(temp); // set the member variable of the stateful session bean
//session.contains(remote.getENTITY()) delivers false
return remote;
}

Any suggestions would be appreciated!

A: 

Your main problem is the system boundaries between the client and server.

If client and server were local (e.g. web UI with EJB3 back-end), you could change the code with your approach with little effort.

But in your case, client and server are remote and the EJB3 entity will indeed become detached when it's returned from the server, which wasn't the case in EJB2 where Entity Bean were remote objects.

Distributed transaction which are started on the client-side work with EJB3, but I would advise against it. I understand however that it might be too much to change.

Possible way to deal with detached entities:

  1. Use an extended persistence context with SFSB, this way the entity remains attached on the client side. I haven't seen any app using that for real, but that might be something to explore.
  2. Send the EJB3 entity back after you've modified it and merge the changes on the server side.
  3. Have a look at H3T. Never used it, but it address some issues related to system and transaction boundaries.

Hope you will find a pattern that suits you.

ewernli
Thx for your answer, it showed me the right direction. I'm now using an extended persistence context while injecting the EntityManager in my SFSBs (@PersistenceUnit(unitName="xyz", type=PersistenceContextName.EXTENDED)
websta