Same WAR file, Same Package, EJB call EJB using remote interface

Question

It is a bit weird to ask this, I just faced an application in development which make extensive use of @EJB Remote to @EJB Remote on the Same Package. I know is a very bad approach since you have a transaction and you do the rest possibly with CDI and managed entities around and if necessary Local EJB with requires new. On this Application I have seen EclipseLink ConcurrencyManager Exceptions locks, Huge RMI IIOP stacks while Lazy Loading. and other gray behaviours. (this Remote EJB do not pass entities but only pointers to @Id between them, then use EntityManager.find , EntityManager.merge and Occasionally EntityManager.refresh)

I couldn't find any answer (may me i was not careful enough) around the web and neither in the EJB specs.

You have 2 Implementation @Stateless EImpl1 and @Stateless EImpl2 each of them implements @Remote E1 and @Remote E2.

on EImpl1 you @EJB E2.

does E2 react like TransactionAttributeType.REQUIRES_NEW ? I would bet on a Yes, but i am not sure, if someone can explain me,.. i would be thankfull

Thanks a Lot for your help.

I Tested and i am pretty sure it is a new Transaction,.. but i have no gold in my profile ,.. LOL — Lorenzo Tama De Micheli, Aug 08 '14 at 05:12
The default transaction attribute for an EJB method is Required, not RequiresNew. Is that what you were asking? — Brett Kail, Aug 08 '14 at 06:16
No, if you inject a remote facade in an EJB will act as RequiresNew or Required ? — Lorenzo Tama De Micheli, Aug 08 '14 at 17:11
No. i know what is the default, but i am asking EJB to EJB Remote (same war ). — Lorenzo Tama De Micheli, Aug 08 '14 at 17:15
http://stackoverflow.com/questions/4136852/understanding-ejb3-jpa-container-level-transactions-and-isolation-level — Lorenzo Tama De Micheli, Aug 08 '14 at 17:29
There is no difference whether the EJB is remote or not, or whether the EJB is in the same WAR or not: the default transaction attribute is Required, not RequiresNew. — Brett Kail, Aug 08 '14 at 18:10

score 0 · Accepted Answer · answered Aug 08 '14 at 22:06

0

ejb 3.1 spec

By default, if a TransactionAttribute annotation is not specified for a method of an enterprise bean with container-managed transaction demarcation, the value of the transaction attribute for the method is defined to be REQUIRED

persistence 2.0 spec

Propagation of persistence contexts only applies within a local environment. Persistence contexts are not propagated to remote tiers.

You see what you see because persistence context is not propagated to remote tiers and default value for TransactionAttribute is REQUIRED.

answered Aug 08 '14 at 22:06

jjd

2,158
2
18
31

2014-09-10 10:33:59.780 INFO 48 HUNT Delegate:EntityManagerImpl@691560424 Intercepted On EntryRemoteFacadeImpl 2014-09-10 10:34:00.769 INFO 48 HUNT Delegate:EntityManagerImpl@691560424 Intercepted On CalledRemoteFacadeImpl Here seems to have the same entity manager, which means that the PC is propagated, what about that ? – Lorenzo Tama De Micheli Sep 10 '14 at 11:40
@LorenzoTamaDeMicheli I assume you are calling an EJB that deployed in the same container through its remote interface, right? If it is the case, I guess your AS tricks you. Some application servers are able to detect local EJB communication automatically and optimize that communication to avoid remote-calling overhead. Even if It is a possibility, you cannot rely on it. Try to deploy your EJB in a different container and see what happens then. – jjd Sep 18 '14 at 08:29
@LorenzoTamaDeMicheli In general, it is better to treat calls through a remote interface as remote ones. Otherwise at some point(for instance if you decide to change your AS or upgrade it to a newer version) you can find you functionality broken and it will be not that easy to find the cause of the problem especially if the code was written long time ago – jjd Sep 18 '14 at 08:30

Same WAR file, Same Package, EJB call EJB using remote interface

1 Answers1