This week's book giveaway is in the JavaScript forum.
We're giving away four copies of Cross-Platform Desktop Applications: Using Node, Electron, and NW.js and have Paul Jensen on-line!
See this thread for details.
Win a copy of Cross-Platform Desktop Applications: Using Node, Electron, and NW.js this week in the JavaScript forum!
  • Post Reply Bookmark Topic Watch Topic
  • New Topic

Stateless or Stateful Session Bean  RSS feed

 
Sirhc Namwen
Greenhorn
Posts: 2
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Good morning all!

It seems standard practice to use a stateless session bean when the process encapulated by it is non-conversational and requires only a single method call.

We're having a debate on a project I'm working on about what may be a caveat to this rule of wrist (see Boondock Saints :-). We have a session bean that technically needs to invoke only one method - but the problem is that this method would return a fairly large amount of data in the form of list items that could be displayed in, say, a table of search results.

Out of concern that the amount of data returned by the bean could kill performance, our lead developer decided to make it a stateful bean and return only a screen-fittable portion of the results at a time.

I'm wondering if some of the EJB experts here could weigh in with their opinions as to what the best approach would be to this problem. Is the lead developer right, or should we be looking at another way of doing things in the 'academic' interest of keeping session beans stateless?
 
Roger Chung-Wee
Ranch Hand
Posts: 1683
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Surely you should be using search filtering to restrict the amount of data that will be retrieved from the DB? I really can't see the need to move away from SLSBs.
 
Valentin Tanase
Ranch Hand
Posts: 704
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Sirhc,

Your lead developer did smart (although not necessary well) and decided to stay on the safety side, employing sun�s Value List Handler design pattern. See:

http://java.sun.com/blueprints/corej2eepatterns/Patterns/ValueListHandler.html

In my opinion there are problems with this approach though and I personally never liked this particular design pattern from Sun (or at least its SFSB strategy). The root cause of all problems is of course the well known fact that SFSBs don�t scale very well. Hence from the beginning the design would assume that this is not a highly available enterprise application and it is destined to support a limited number of concurrent users only. Even worse, caching large amount of data on the server side in this manner is far from providing a very optimal solution. Your dev lead was considering reducing the network traffic. That�s a good point. However, one think that he might not be considering is that network overhead will mostly occur anyway. To make long story short, in a clustered environment the container will use an in-memory replication of SFSB data. This means that the container will pick a server instance as the primary and another one as the secondary. It will always keep the session data in sync, using a reliable IP-multicast protocol. If the data on the primary gets changed, the container will have no choice but to copy it to the secondary. You can imagine the effect of copying large amount of data across the cluster. Using HttpSession instead might provide better performance (containers could replicate HttpSession data more efficiently). Hence network traffic overhead will still exist.
Back to your question let�s seek if we might provide other solutions. A very simple one would be to use SLSB and HttpSession. It�s a beginning but caching such large set of data in the session is not very optimal either. Besides if you�d like to optimize the session replication across the cluster, is always better to store more fine grained objects rather than fewer coarse grained objects and this might not fit your DTO-based design.
Another solution that might work with some data models is to use SLSBs that have methods capable of returning some range of data. Something like this:

This way you won�t need to cache the data but would require subsequent database calls for showing the next page.
One other suggestion would be to look at your container and check for any vendor specific caching solutions. Weblogic for example uses read-only ejbs, while JBoss can cache graphs of POJOs.
Regards.
 
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!