-
1. Re: EJBClient.getUserTransaction() failover behavior with WildFly Cluster
pferraro Jul 29, 2014 9:34 AM (in response to julien.topcu)The EJBClient.getUserTransaction(...) method is a bit hacky - you wouldn't want to use this within the context of a cluster.
Instead, why not wrap your transaction logic within a @Remote @Stateless EJB? That way you would lookup the SLSB, which would be load balanced against the cluster, and the UserTransaction (and any EJBs you might need) can simply be injected into the EJB. This way your code will be both cluster friendly and still work against a single server.
-
2. Re: EJBClient.getUserTransaction() failover behavior with WildFly Cluster
julien.topcu Jul 29, 2014 10:30 AM (in response to pferraro)Thanks Paul.
What I also understood, is that we are no longer able to retrieve an UserTransaction through JNDI lookup e.g. ic.lookup("UserTransaction"), right ?
That was the reason why I switched to EJBClient.getUserTransaction(...) method.
-
3. Re: EJBClient.getUserTransaction() failover behavior with WildFly Cluster
pferraro Jul 29, 2014 7:11 PM (in response to julien.topcu)A remote client cannot retrieve a UserTransaction via jndi lookup.
If you encapsulate your transaction logic within a @Remote EJB, you can just inject the UserTransaction via @Resource, or via getUserTransaction() from an injected SessionContext.
-
4. Re: EJBClient.getUserTransaction() failover behavior with WildFly Cluster
valsaraj007 Feb 11, 2015 6:36 AM (in response to pferraro)Hi pferraro,
If I move the entire logic to SLSB (using CMT), what I need to do is lookup that SLSB from remote and call that single method which does all inside the bean and return the output.
if I use BMT, I have to write something like this, http://www.java2s.com/Code/Java/EJB3/UseUserTransactionInClientSide.htm.
Is that correct?
Thanks!
-
5. Re: EJBClient.getUserTransaction() failover behavior with WildFly Cluster
smarlow Feb 11, 2015 10:45 AM (in response to pferraro)Paul Ferraro wrote:
The EJBClient.getUserTransaction(...) method is a bit hacky - you wouldn't want to use this within the context of a cluster.
Instead, why not wrap your transaction logic within a @Remote @Stateless EJB? That way you would lookup the SLSB, which would be load balanced against the cluster, and the UserTransaction (and any EJBs you might need) can simply be injected into the EJB. This way your code will be both cluster friendly and still work against a single server.
Will each client (SLSB) invocation with the same UserTransaction, be distributed to different cluster nodes or are we UserTransaction sticky? The advantage of being UserTransaction sticky, would be that transaction scoped entity managers operations will always occur on the same node.
-
6. Re: EJBClient.getUserTransaction() failover behavior with WildFly Cluster
wdfink Feb 11, 2015 11:30 AM (in response to smarlow)It's not only that all entity managers might on the same node.
The problem is if you use EJB CMP that means there is a 1.Level cache which hold some Entities on a local node.
The same appears for JPA which use Hibernate as implementation.
In both cases it might happen that you read stale data, depend on the balancing strategie and number of nodes, i.e. if you start a Tx and read a value with a remote call it might go to node1, next is an update going to node2. If the next read is again on node1 the value is still in the 1L cache and stale data are used.
-
7. Re: EJBClient.getUserTransaction() failover behavior with WildFly Cluster
valsaraj007 Feb 11, 2015 10:56 PM (in response to wdfink)Then what is the best method to do this? Lookup UserTransaction is not supported in latest stable release of WildFly.
-
8. Re: EJBClient.getUserTransaction() failover behavior with WildFly Cluster
pferraro Feb 16, 2015 8:53 AM (in response to valsaraj007)Correct.
-
9. Re: EJBClient.getUserTransaction() failover behavior with WildFly Cluster
wdfink Mar 5, 2015 6:59 AM (in response to valsaraj007)From my perspective I would wrap the transaction with a SLSB inside of the server as client side transactions are more complex and often difficult to migrate.
-
10. Re: EJBClient.getUserTransaction() failover behavior with WildFly Cluster
sph007 Apr 29, 2015 2:13 PM (in response to wdfink)What would you recommend if your client needs to perform additional work (e.g. database calls or service calls) that should be atomic with multiple server-side EJB calls? We are integrating with a vendor product that provides the EJBs, so moving our custom logic/integrations to the server side is not an option.
Thanks,
Scott
-
11. Re: EJBClient.getUserTransaction() failover behavior with WildFly Cluster
wdfink Apr 30, 2015 7:12 AM (in response to sph007)I think in that case you need to have a client side UserTransaction with all the drawbacks. There are some enhancement requests for WildFly to improve the behaviour and use of UTx.
But in any case the client need to handle problems with the transaction, i.e. if you call several EJB's the transaction will fail if you loose one already used server.
If you access EJB's with JPA inside and need to see updates across different invocations, you need a stickyness to one server as the JPA PersistenceManager is stateful with the underlying cache (might happen that the updates are not already stored in the database during transaction).
So it should be well considered if such approach is used.