• Post Reply Bookmark Topic Watch Topic
  • New Topic

Concurrent access to EJB session data is having problems

 
Seema Hanji
Ranch Hand
Posts: 37
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I am not sure whether this is the right forum to post this question. Please bear with me.

We have a very big J2EE web application. Following is our application design explained in brief :

- A set of Struts action classes. which don't have any instance variables declared.
Hence they are all stateless.
- These action classes, for each request retrive session data object from EJB stateful session and store it back in session at the end of request.
- Session object is externalizable with all serializable data as members. This session data object has a Collection of sub-objects of same type.
- There is a static factory class, which reads xml config file to create Collection of sub-objects to be stored in main session object and these sub-objects are cached in the factory. And factory gives deep copy of these objects instead of same objects, hence main session object will be working on seperate set of these sub-objects for each session.
- We have a very simple Stateful session EJB which has main session object.


This wholething works perfect when there is no concurrent access. But, while doing performance test, when hit with multiple users at the same time, we are seeing some of the sub-objects missing from main session object . What could be the reason for this ? we don't see any activation /passivation going on also, as our max-bean-in-cache is set to a very high number.

We are using Weblogic 8.1 as app server and have set weblogic param <enable-call-by-reference>True</enable-call-by-reference> in weblogic-ejb-jar.xml.


Please help ...any clues, ideas will be appreciated.
Thanks
 
Valentin Tanase
Ranch Hand
Posts: 704
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Seema,

If I understand your design correctly, then you are using SFSB for caching some session specific information. Moreover it occurs to me that your cache is unique per application and it�s meant to be shared by all users. If that�s the case then I don�t believe this is going to work; or at least not that easy. One very important reason is that with SFSB every client will talk to a different bean instance. Hence if user A use the static factory class (which by the way must be designed thread safe) to build the list of sub-objects and add these objects to the main cache which is managed by the SFSB and user B does the same thing, then the result would be that A and B will update different caches, maintained by different SFSB instances. No way to add both lists of sub-objects to the same SFSB instance. Not unless you change your code and use the ejb handler in order to make sure that all your users talk to the same bean instance. But if you do this with SFSB, then the container will throw an exception (as the specifications say). Luckily weblogic has a way to overcome this limitation (see the allow-concurrent-calls deployment element), but now you have to code your SFSB thread safe. Another problem that you might encounter is when you will deploy yourr app in a clustered environment. Then your static factory cannot be replicated among the cluster and this might or might not be a major problem for your application as well. Finally you have to understand that for SFSB weblogic replicates the session information among all servers in a cluster (using ip-multicast) in a very inefficient way (HttpSession information get much better optimized) and therefore caching large amount of data in session beans is not a great design choice either.
As you might see there are lots of problems for you to overcome. Bottom line is that you might have it working, but your solution is far from being nice, elegant or optimal. You also remember that in the lifetime of your application probably codding will represent less then 10%, while maintenance means more than 90%.
Regards.
 
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!