aspose file tools*
The moose likes EJB and other Java EE Technologies and the fly likes Reentrant EJB ?? Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of The Java EE 7 Tutorial Volume 1 or Volume 2 this week in the Java EE forum
or jQuery UI in Action in the JavaScript forum!
JavaRanch » Java Forums » Java » EJB and other Java EE Technologies
Bookmark "Reentrant EJB ??" Watch "Reentrant EJB ??" New topic
Author

Reentrant EJB ??

Harpreet Hira
Ranch Hand

Joined: Sep 27, 2001
Posts: 72
Could any one elaborate what is a re-entrant?
Tim Holloway
Saloon Keeper

Joined: Jun 25, 2001
Posts: 16019
    
  20

Re-entrant is thread-safe without the need for (coarse) blocking. In other words, two or more processes can use the code simultaneously without harming each other or objects dependent on the code.


Customer surveys are for companies who didn't pay proper attention to begin with.
Steve Chernyak
Ranch Hand

Joined: Oct 19, 2000
Posts: 113
Im confused.
As far as EJBs and reentrancy goes, I though that if a bean is deployed as reentrant that means that the beans client is allowed to callback methods of a bean in the same thread of execution, but other clients would still not be allowed to execute methods on that instance of the bean.
Please let me know where im wrong.
SteveC
Ram Dhan Yadav K
Ranch Hand

Joined: Aug 13, 2001
Posts: 321
Hi,
Reentrance can be explained like this.
Client --> EJB A --> EJB B --> EJB A
Client calling EJB A which inturn calls EJB B which inturn calls EJB A. That means EJB A is being being entered twice which is reentrance. EJB usually can have only one client at a time i.e a client enters and exits a bean, there is no sencond client entering it while it is serving a client, ejb specification. In reentrance case, its the same client transaction and so it allows to reenter the bean. But this practice is highly discouraged.


Ram Dhan Yadav (SCJP, SCWCD, SCJA-I, IBM EC(483))
"We are what we repeatedly do. Excellence, then, is not an act, but a habit."
Dieter Cailliau
Greenhorn

Joined: Jan 17, 2002
Posts: 11
Why is an ejb non-re-entrant by default? What's the good thing about this restriction? I don't see the point, i would never have thought about "hey maybe we could provide a mechanism that disallows ejb A to call back itself with another ejb in between". So what?
Matjaz Juric
Author
Ranch Hand

Joined: Aug 02, 2001
Posts: 65
Hi Dieter,
Originally posted by Dieter Cailliau:
Why is an ejb non-re-entrant by default? What's the good thing about this restriction? I don't see the point, i would never have thought about "hey maybe we could provide a mechanism that disallows ejb A to call back itself with another ejb in between". So what?

If an entity bean is marked as non-reentrant, then a container can prevent illegal concurrent calls from clients.
A reentrant entity bean on the other hand has to be programmed so that a loopback call is allowed. The container however cannot distinguish from a loopback and concurrent call from a different client, the developer has to avoid situations that could lead to a concurrent call in the same transaction context, which is illegal.
Matjaz


Matjaz Juric<br />Author of <a href="http://www.amazon.com/exec/obidos/ASIN/186100544X/qid%3D1008676221/sr%3D8-1/ref%3Dsr%5F8%5F5%5F1/103-4928879-8274265" target="_blank" rel="nofollow">Professional J2EE EAI</a> and <a href="http://www.amazon.com/exec/obidos/ASIN/1861005083/ref=ase_electricporkchop" target="_blank" rel="nofollow">Professional EJB</a>
Dieter Cailliau
Greenhorn

Joined: Jan 17, 2002
Posts: 11
dear Matjaz
i still don't get it.
non-re-entrant (=default) means:
"a container can prevent illegal concurrent calls from clients."
Which concurrent calls are illegal?
I thought entity beans were multi threaded!
Last paragraph: do you mean a loopback is illegal, unless re-entrant is specified? Then my original question still is: why did the j2ee inventors made this a special case in the first place? What is so specific to a loopback that it needs special treatment?
You also say: "The container however cannot distinguish from a loopback and concurrent call from a different client." If so, why is the explanation (specs) of "re-entrant" only about loopbacks, and not about concurrent clients? If the container can not distingush those?
come one Matjaz, enlighten me!
Ram Dhan Yadav K
Ranch Hand

Joined: Aug 13, 2001
Posts: 321
Hi Dieter,
Here is an explanation on multithreading of EJB's from Pg No:242 of Mastering EJB II of EdRoman.
One great benefit of EJB is you don't need to write threaed-safe code. You design your enterprise beans as single-threaded componenets and never need to worry about thread synchronization when concurrent clients access your componenet. Your EJB container automatically instantiates multiple instances of your component to service concurrent client requests.
The container's thread services can be both a benefit and a restriction. the benefit is that you don't need to worry about race conditions or deadlock in your application code. The restriction is that some problems lend themselves well to multithreaded programming, and that class of problems cannot be easily solved in an EJB environment.
So why doesn't the EJB specificatin allow for multithreaded beans? EJB is intended to relieve compoment developets worry about threads or thread synchronization. The EJB containerr handles those issues for you by load-balancing client rquest to multiple instances of a single-threaded component. An EJB server provides a highly scalable environment for single-threaded components.
If the EJB specification allowed for beans to control threads, then a pandoras box of problems would result. For example, an EJB container would have a very hard time controlling transaction if beans are randomly starting and stopping threads, especially because transaction information is often associated with a thread.
One alternative to threading is to use transactional messaging API, such as JMS, that allows for asynchronous actions to occur in a distributed environment. JMS enables you to safely and reliably acheive multitasking without the beans themselves messing arround with threads.
The bottomline is that EJB was not meant be a Swiss army knife, solving every problem in existance. It was designed to assist with server-side business problems, which are largely single-threaded. For applications that absolutely must be multithreaded, EJB may not be the correct choice of distributed object architectures.

Regarding reentrance problem, there is a very clear explanation in EJB book my Mason ,Hafel Orilley's. I will get back if i am able to get the book.
Harpreet Hira
Ranch Hand

Joined: Sep 27, 2001
Posts: 72
Hi,
I thank you all for such a good explaination. The following could prove to be more helpful -
10.5.11 Non-reentrant and re-entrant instances
An entity Bean Provider can specify that an entity bean is non-reentrant. If an instance of a non-reen-trant
entity bean executes a client request in a given transaction context, and another request with the
same transaction context arrives for the same entity object, the container will throw an exception to the
second request. This rule allows the Bean Provider to program the entity bean as single-threaded,
non-reentrant code.
The functionality of entity beans with container-managed persistence may require loopbacks in the
same transaction context. An example of a loopback is when the client calls entity object A, A calls
entity object B, and B calls back A in the same transaction context. The entity bean’s method invoked
by the loopback shares the current execution context (which includes the transaction and security con-texts)
with the Bean’s method invoked by the client.
If the entity bean is specified as non-reentrant in the deployment descriptor, the Container must reject an
attempt to re-enter the instance via the entity bean’s component interface while the instance is executing
a business method. (This can happen, for example, if the instance has invoked another enterprise bean,
and the other enterprise bean tries to make a loopback call.) If the attempt is made to reenter the instance
through the remote interface, the container must throw the java.rmi.RemoteException to the
caller. If the attempt is made to reenter the instance through the local interface, the container must throw
the javax.ejb.EJBException to the caller. The container must allow the call if the Bean’s
deployment descriptor specifies that the entity bean is re-entrant.
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.
Concurrent calls in the same transaction context targeted at the same entity object are illegal and may
lead to unpredictable results. Since the container cannot, in general, distinguish between an illegal con-current
call and a legal loopback, application programmers are encouraged to avoid using loopbacks.
Entity beans that do not need callbacks should be marked as non-reentrant in the deployment descriptor,
allowing the container to detect and prevent illegal concurrent calls from clients.
 
 
subject: Reentrant EJB ??