There was a related thread on this last week; cf. http://swjscmail1.java.sun.com/cgi-bin/wa?A2=ind0204&L=ejb-interest&D=0&; P=1833 and ensuing discussion.
Regarding speed, it is important to consider the execution context. Presumably the example in the message cited below is a simple in-memory operation. On the other hand, if the SSB call hits the database, as is often the case, then the time is dominated by IO rather than the method call differential. So, to extend the example, if the actual duration of the call under load is as follows: 1.0000001 sec with a Java class 1.001 sec with a SSB then using the Java class is less than .001 times faster than a SSB, not 10,000 times faster. There is no pat rule for which is better, but in an EJB project it is preferable to look at code integrity and quality of service first, since it is usually easier to analyze than performance. Fred Loney Spirited Software, Inc. www.spiritedsw.com ----- Original Message ----- From: "Mike Bresnahan" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Sunday, April 07, 2002 9:55 AM Subject: Re: SSB vs. Singleton > My preliminary tests on WebSphere 4.0 show that a local Java function call > is 10,000 times faster than a call to a stateless session bean (10E-8s vs > 10E-4s on my PIII 1GHz). Therefore, I would recommend using the singleton. > > Mike Bresnahan > > P.S. I'm CCing you because I have yet to see one of my posts make it through > the list. > > > -----Original Message----- > > From: A mailing list for Enterprise JavaBeans development > > [mailto:[EMAIL PROTECTED]]On Behalf Of George Constantine > > Sent: Saturday, April 06, 2002 4:56 PM > > To: [EMAIL PROTECTED] > > Subject: SSB vs. Singleton > > > > > > Hello everyone > > > > I'm wondering why I'd want to use a Stateless Session EJB if I do > > not need to call it remotely, and also do not need TX support. > > > > Seems like many people use SSBs that are called by other SSBs in > > the same JVM, and where they do not necessarily need TXal method calls. > > > > I asked someone this question once, and the reply was, "You get > > automatic instance pooling, so you get higher performance." I > > thought about this and wondered whether just using a plain old > > Java singleton would work better. > > > > This is assuming that the method calls do not access state in the > > object. Although this should be true for an SSB, it is not > > always true, as only one method acts on an SSB instance at once. > > So a method can put stuff in member variables, and take stuff > > out, just for convenience. The only thing to watch out for is to > > not depend on the values of the member variables between method calls. > > > > So assuming we don't need that "convenience", the method calls > > are stateless, and therefore don't need to be synchronized (in > > the case of a Singleton) or anything. So the situation boils down to: > > > > 1) A pool of SSBs that can serve these stateless requests > > > > or > > > > 2) A single instance of an object (the Singleton) that serves > > these stateless requests > > > > or even > > > > 3) A class with static methods that serve all these requests > > > > Does one perform better than the other? Obviously 1) has more > > objects in memory, so that's bad. But does it serve the requests > > faster? With no synchronization of the Singleton? > > > > If 2) (or 3)) is better, I know a lot of people who should be > > changing their code. > > > > Thanks for the feedback, folks. > > > > George > > > > ================================================================== > > ========= > > 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". > > =========================================================================== 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".
