I have a *stateful* session bean method which returns a list of items from the database.I call my session bean method using a servlet.Everything works fine and I am getting the results back. Now if I refresh the browser just before any results are displayed(while the browser icon is spinning) I am getting a BeanNotReentrantException from the session bean.
It looks like the same method of the session bean is getting called before the first method returns.
Does this mean that I should not put any methods in stateful session beans that takes a while to return.
Is there any solution to this problem?I can not ask the user not to click refresh while the browser is doing something.
What container is that?!?!
have u checked the Re-entrant field in DD(in ejb-jar.xml) to FALSE
I really think your most stable and portable solution is to not use a stateful bean. Is there a reason you are using a stateful bean? If the bean is simply supplying results to populate a web form, then I would think a stateless bean would suffice.
The issue is occuring because you on the refresh you are making two concurrent calls into the same stateful instance. This is illegal in EJB (although I might argue the proper exception is InvalidTransaction, but thats not worth quipping about) for a stateful bean.
I have just one stateful bean (the customer) which stores customer data.Almost all the functionality uses this information to display data( shoppingcart,prev. purchases, coupons etc). Now obviously, I put some of the business methods like login ,getMyCoupons in the same customer bean.
Now ,what you are saying is do not use sateful beans at all.
Or if I really need them use it just for storing data, and use an additinal stateless bean for business methods.
I heard that you should minimize the use of stateful beans for performance reasons.But never thought that I should never use them.
Now I have minimized the use of entity beans because of all all those reasons spread across the web. This means my J2EE architecture becomes a bunch of stateless beans(getting created everytime I need to call a method),that would interact with each other via servlets.Hmmm....!
This is one the reasons why stateful session beans are evil. When the user has multiple browser windows open, and uses them in a relatively concurrent fashion, BeanNotReentrantExceptions are eventually bound to occur. One could probably argue that when facing incoming concurrency, the EJB specification should provide a queue of calls to be served to a particular bean (where queue maximum length can be specified similarly to bean pool maximum size).
You can mitigate the situation by keeping calls to stateful session beans very short (simple getters etc.), not using stateful session beans at all, as recommended above (good advice!), or synchronizing on the client side on some object (perhaps the stateful bean stub). The last option doesn't obviously work, though, if the bean can be accessed from multiple VMs concurrently.
Interesting...Is there anyone out there who actually used all the features J2EE+EJB offers..or is it always like you had to avoid the 'cool features' because of practical reasons. I am talking about EJB 1.1,
1. using CMP entity beans wherever possible, which I could not because a real life app is going to have database joins and auto generated sequence no:s
2. Entity beans for interacting with the database. I had to always use session-bean-calling-jdbc because of performance reasons, unless there is a transaction involved. Now how many transactional functionality would be there in a normal application? two or three?
3. Stateful session beans. It is kind of useless if you can not put obvious business methods in a session bean.
4. Stateless beans : wouldn't you rather go with a simple java class or a java class with static methods, inorder to avoid all the hazzle of doing JNDI lookups, coding 3 different interfaces making RMI calls thru the network ,and so on..reasons.
5. Does it mean, although J2EE sounds like a good framework, it is not practical at all? ( Except servlets and JSPs which I think really serves the purpose)