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
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."
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?
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>
Joined: Jan 17, 2002
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
Joined: Aug 13, 2001
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.
Joined: Sep 27, 2001
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.