Well, none of those 3 situations apply to the class in question. I saw instance pooling buying me the same thing any kind of resource pool buys you: "concurrently" satifying N requests with < N instances of the resources. Here, the resource is an instance of my class, rather than a database connection or something like that.
Thanks, Mike --- Fred Loney <[EMAIL PROTECTED]> wrote: > 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". > > > __________________________________________________ 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".
