The value of pooling is proportional to the fixed overhead of object construction and initialization. If creating the data accessor object is cheap, then it's easier to make a new one and discard it when done. Data accessor object cost is usually dominated by the per-request effort to build and execute the query, which is incurred regardless of pooling. Your situation may differ.
----- Original Message ----- From: "Mike Dunbar" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Wednesday, April 03, 2002 11:39 AM Subject: Re: Container Instance Pooling Justification for Stateless Session EJB? > 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". > > =========================================================================== 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".
