Hi
I've faced similar problem sometime back. What we did was to use a
singleton whuch is a proxy to the session bean. This proxy would invoke
the session bean methods just once and cache the data in itslef. All
subsequest requests for the cached data would not involve session bean
method invocations.
G.Vijay
Dominic
Cioccarelli To: [EMAIL PROTECTED]
<dcioccarelli@FRE cc:
E.FR> Subject: Why not use just a single
Stateless
Sent by: A Session Bean?
mailing list for
Enterprise
JavaBeans
development
<EJB-INTEREST@JAV
A.SUN.COM>
02/15/2002 08:58
AM
Please respond to
Dominic
Cioccarelli
O.k, I know that this subject has come up a few times, but I'm not
satisfied
with any of the answers, so I'll ask it again ;-).
Given that a stateless session bean can't maintain conversational state,
why
bother creating multiple instances (instance pools)? It would seem to be
more efficient just to use a single instance to serve all clients.
>From what I can see the reason seems to be that with EJBs (unlike RMI)
multiple clients can't invoke methods on a single EJB at the same time.
Requests are serialized. Therefore instance pools are used to increase
performance.
Personally I feel that not allowing concurrent access to _stateless_
session
beans is an unnecessary constraint. Sure it means that bean developers
don't
need to deal with concurrency issues, but it also decreases performance
leading to the use of instance pools and the associated object
instantiation
overhead.
If I were to use a single RMI server object, on the other hand, 1000
clients
could theoretically invoke methods on it simultaneously. Concurrency would
only be a problem if I had methods accessing variables at the object scope
(but good programmers should be conscious of these issues).
The reason I ask is that I have an object which needs to be implemented as
a
stateless session bean. The problem is that when it is instantiated it
needs
to load (and cache) a lot of data. Our current implementation uses a
singleton which is very efficient as this (the information is loaded only
once for all clients). Switching to a stateless session bean would mean
that
this information would need to be loaded for each instance. Furthermore,
performance wouldn't be as good, i.e. if I had 10 clients and 5 beans, then
5 of the clients would be left waiting. In comparison, an RMI server object
could serve all 10 clients simultaneously (using a single object)!
Conclusion: Is the thread safety provided by a stateless session bean worth
the associated constraints?
===========================================================================
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".
