[Clustering/JBoss] - Is it possible to factor out jboss rmi and use in a j2se env
by mneighbors
We are looking at clustering the middle tier for one of our products. This product is a 3-tier j2se application that uses jdo. Clustering between the middle tier and the back end can be handled by the jdo implementation. We want to stay with jdo if possible. We also are going to stay j2se. Many aspects of j2ee we already have.
More of a concern is load balancing rmi between the clients and clustered middle tier. We may drop rmi for the cluster and just provide soap but would like to support rmi.
The client in our product exports an rmi object and sends a proxy to the server at login time. This is used for server-to-client asynchronous push. When the client is configured for soap a poll is used instead.
I just read about the jboss clustering/failover implementation at http://www.ieeetcsc.org/newsletters/2003-02/labourey.html. The following paragraph is a quote from this link.
"One interesting facet of this communication pattern is that the proxy remains transport agnostic: only the transport-invoker knows about the transport and protocol used to make the invocation travel through the network. Currently, JBoss provides RMI/JRMP, IIOP, HTTP, SOAP and optimized invokers."
And so it appears that it's more than just rmi that would have to be factored out. I should rephrase the question.
Is it possible to factor out the jboss rpc communication layer and use it in such a j2se application?
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3980875#3980875
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3980875
19 years, 6 months
[EJB 3.0] - Re: EntityManager.lock() issues
by ablevine1
anonymous wrote :
| The approach I was trying to use:
|
| AEntity a = manager.find(AEntity.class, aId);
| manager.lock(a, LockModeType.READ);
|
| I think now it's not the way to go, because it's not atomic: Different competing threads could adquire an entity representing that database row before one of then reaches the lock.
|
I had a simlar problem and came up with this solution: Since multiple threads can get then entity before locking it, once you get the lock, refresh the entitiy, then you will have the latest copy and you can then update it without overwriting previous updates:
| AEntity a = manager.find(AEntity.class, aId);
| manager.lock(a, LockModeType.READ);
| manager.refresh(a);
| // now do stuff
|
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3980871#3980871
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3980871
19 years, 6 months