There are three situations where the data retrieval class benefits from being a SSB:
1) if the class references an Entity Bean or more than one Session Bean, then the SSB serves as a mediator for functional partitioning and potentially reduces RMI overhead for remote EJB calls. 2) if the class requires authorization, then the SSB permits declarative authorization. 3) if the class uses a shared non-pooled resource, then the resource can be effectively managed as an EJB env-entry. Otherwise, I don't see a benefit from making the class a SSB. Since a non-transactional SSB has no useful context, instance pooling doesn't buy you anything. See also the Fast-Lane Reader pattern at http://java.sun.com/blueprints/patterns/j2ee_patterns/fast_lane_reader/i ndex.html. Fred Loney Spirited Software, Inc. www.spiritedsw.com ----- Original Message ----- From: "Mike Dunbar" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Wednesday, April 03, 2002 10:13 AM Subject: Container Instance Pooling Justification for Stateless Session EJB? > I have a Java class that provides various data-retrieval methods > (non-transactional). A design decision was made to publish it is a > local stateless session EJB in our web app. As I am doing so, I can't > help asking myself "why the heck is this being made an EJB?". > > Since we have the benefit of connection pooling outside of EJB, and > their are no transactions or remote clients, the only possible benefit > I can see is that the container would probably pool instances of the > bean, and this could be useful at high volume times. Am I missing > something else? Does this alone justify making it an EJB? We will > deploy to a cluster, but that shouldn't impact this decision, right? > > Thanks, > Mike > > __________________________________________________ > Do You Yahoo!? > Yahoo! Tax Center - online filing with TurboTax > http://taxes.yahoo.com/ > > ======================================================================== === > To unsubscribe, send email to [EMAIL PROTECTED] and include in the body > of the message "signoff EJB-INTEREST". For general help, send email to > [EMAIL PROTECTED] and include in the body of the message "help". > =========================================================================== To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message "signoff EJB-INTEREST". For general help, send email to [EMAIL PROTECTED] and include in the body of the message "help".
