Reentrant okay in BDOM?

[Saha Kumar]

Hello All,

I have read previous postings on this forum that say you can have reentrant entity beans...but what about the class diagram in general. I find that as I work through the use cases, I need to introduce some reentrant classes.

Is there any reason that reentrant classes in the class diagram are unacceptable?

Is adding new associations to the original BDOM considered changing it?

Thanks for any input.

-Saha

[Raghubir Bose]

This is what I know

Taken from Enterprise JavaBeans by Richard Monson-Haefel, "EJB, by default, prohibits concurrent access to bean instances. In other words, several clients can be connected to one EJB object, but only one client thread can access the bean instance at a time. If, for example, one of the clients invokes a method on the EJB object, no other client can access that bean instance until the method invocation is complete."
So, to answer your question, two users will never access an Entity Bean concurrently.

Some entity beans may require loopback calls, where bean A is invoked, in turn invoking bean B, which then invokes a method call on bean A. This kind of concurrency is tricky and is best avoided."

Also IBM says
"Using threads and reentrancy in enterprise beans:
--------------------------------------------------
Session beans can never be reentrant; that is, they cannot call another bean that invokes a method on the calling bean. Entity beans can be reentrant, but building reentrant entity beans is not recommended and is not documented here. The EJB server enforces single-threaded access to all enterprise beans. Illegal callbacks result in a java.rmi.RemoteException exception being thrown to the EJB client."

And Finally from Sun

(http://archives.java.sun.com/cgi-bin/wa?A2=ind0307&L=j2ee-interest&F=&S=&P=2114)

"Re-entrant entity beans must be programmed and used with caution. First, the Bean Provider must code the entity bean with the anticipation of a loopback call. Second, since the container cannot, in general, tell a loopback from a concurrent call from a different client, the client programmer must be careful to avoid code that could lead to a concurrent call in the same transaction context."

This is section 10.5.12 of the EJB2.0 spec.

So I feel that even though it is technically possible to use a re-entrancy in entity bean , it is best to avoid.

[Saha Kumar]

Thanks, Raghubir for the very detailed and well-researched answer. I will take care not to introduce any associations which may permit reentrant code.

One more question, is it correct that the following is reentrant:

A calls method in B
B calls method in C
C calls method in D
D calls method in E
E calls method in A
?

Thanks for your help.

-Saha

[Raghubir Bose]

with my understanding it is re-entrant.

Let me explain what I understand about this in details :
The situation is

A calls method in B
B calls method in C
C calls method in D
D calls method in E
E calls method in A

This is an example of loopback or re-entrance.

Monsoon Haefel says
"Since entity and session beans interact with each other using remote/local interfaces and not directly so when bean A operates on bean B,it does so the same way an application client would, by using B�s remote or local interface as implemented by an EJB object.This allows the EJB container to interpose between method invocations from one bean to the next to apply security and transaction services.From a bean�s point of view, only clients perform business method invocations.When a bean instance has a business method invoked, it cannot tell the difference between a remote application client and a bean client."

So for every invocation to a bean, the bean undertands that its a client call, no matter it is called by its brother bean.

So the key here is the transactional context, if the transactional context is not the same then there is no problem , however if the transactional context is the same, then you have chances of getting into trouble.Since in this situation the problem with reentrant code is that the EJB object�which intercepts and delegates method invocations on the bean instance�cannot differentiate between reentrant code and multithreaded access within the same transactional context.So for concurrent access this might result in dirty data.

So the importance of transactional context is paramount here for safe design.

[Saha Kumar]

Thanks Raghubir!

This definition of re-entrant code as applied to EJB is very useful in the BDOM design as well as everyday EJB design. I had looked for this kind of information before but couldn't find it.

Thanks from myself and the other javaranchers!

-Saha