Jon Tirsen wrote:
> A stateless session does not have any state (duh!) which makes it pretty
> useless to handling any state at all (duh!) (such as a ro-data-cache).
>
[Randy Stafford] Others who have considered the subject
thoughtfully have reached different conclusions. For example Richard
Monson-Haefel, author of O'Reilly's Enterprise Java Beans book and a
subscriber to this list, writes on pg. 175 of his book that "[the EJB
definition of a stateless session bean doesn't] mean that a stateless
session bean can't have instance variables and therefore some kind of
internal state." All the spec says is that a stateless session bean
contains no *conversational* state, defined as state describing the
conversation of a specifc client/instance pair. In an application I'm
currently working on, I'm using a stateless session bean for an object ID
generation service, and the session bean instances definitely maintain
internal state: the next, and last, OIDs available to be given out from the
current OID block. The key point is that no client should know or care
which instance of a stateless session bean services its invocation. If the
service to be provided by the bean is a read-only database cache, and all
bean instances are initialized the same way, then any instance should be
able to provide equivalent service to a client. Stateless session beans
also avoid the passivation and activation events to which stateful session
beans and entity beans must respond - and the overhead of passivating and
activating a cache of read-only data of sufficient size may prohibit the use
of those types of EJBs for this purpose.
That said, the difficulty with using stateless session beans for
services such as these is that it is extremely difficult (if not impossible)
to enforce systemwide singleton semantics with EJB 1.0. In a scenario with
multiple client VMs, or a single but multi-threaded client VM, an
application could pass around a handle or a reference to a singleton
stateless session bean, but then the application has to take responsibility
for implementing some kind of external synchronization scheme to prevent a
second client invocation from occurring on the singleton bean instance while
it was servicing a first client invocation. I hear that a later version of
the EJB spec is addressing this singleton issue, but for now one must
compromise. The compromise I reached with the OIDGenerationService was to
pool, within client VMs, stub references to remote beans, and synchronize
access to the pool. Depending on application semantics, this approach
results in the creation of at least one bean instance per client VM, which
was tolerable in my case. Whether this result would be tolerable for a
read-only data cache would likely be a function of peak concurrent demand
for the service and time and space required to initialize the cache. Too
many active instances of a large stateless session bean -based cache would
likely hamper a container's ability to "manage the size of its working set",
as the spec puts it.
> A session is not shared between clients which makes it pretty useless
> since
> the point of a cache is to optimize as many requests for data as possible.
>
[Randy Stafford] From the EJB 1.0 spec, p.36: "Since all instances
of a stateless session bean are equivalent [from a client's perspective], a
container can choose to delegate work to any available instance." Thus
stateless session bean instances can be "shared between clients" if the
container implements "instance swapping", as Monson-Haefel calls it on p.51
of his book.
> The entity seems to be the only way to implement caches in EJB (since they
> are shared by clients), but unfortunately they cannot be used either (at
> least not in portable manner). The entities state is for most containers I
> have tried flushed and read from the underlying datasource for each
> transaction. I guess some containers could implement some kind of
> intra-transaction cache of entities, but I haven't seen in the containers
> I
> have tried.
>
[Randy Stafford] Using a single entity bean to implement an entire
read-only cache would arguably violate the intent of the entity EJB type.
Creating a separate entity bean for every RDBMS tuple would allow caching
(between activate/passivate events), but would result in a heck of a lot of
distributed objects if the amount of data to be cached was large.
> Currently there are two alternatives, either model it as a non-EJB
> CORBA-service or use the database data-cache.
> The database-vendors have some decades of experience in handling data so I
> guess they are the best bet to go for.
>
[Randy Stafford] I agree that singleton services such as these are
currently best implemented as CORBA services, due to the current
difficulties of implementing singleton stateless session beans. <vendor>And
implementing these types of caching mechanisms is exactly the intent of
GemStone's Persistent Cache Architecture.</vendor>
> Plumbing work such as caching of data is not what the EJB-specification is
> about. It is about programming pure business-logic without having to deal
> with things like these. It's the container-provider who should worry about
> these things.
>
[Randy Stafford] I disagree. A large part of the EJB spec is about
specifying the state model and relevant lifecycle event callbacks for each
type of EJB, for the precise reason of allowing bean developers to
synchronize state cached in bean instance variables with persistent storage
at the appropriate points in a bean's lifecycle.
Mike Fontenot wrote:
> > I'm not sure how you tell clients NOT to call the EJB server
> > until the cache
> > is loaded
>
[Randy Stafford] Ingo Schuster wrote:
> > > 2. If I choose a stateless session bean:
> > > - Will I get trouble with timeouts (the container removes the
> > > bean and I
> > > have to "save the cache")?
>
[Randy Stafford] Yes, the container could expire the bean, and
client code would have to be prepared for that event - but I wouldn't think
you'd care about "saving the cache" if it's read-only. More likely you'd
want to initialize the cache downstream of the ejbCreate method, or lazily
as business methods were called.
> > > 3. Is there an alternative to using EJBs - e.g. servlets ? But in
> > > that case my
> > > application would needed be accessed through the webtier - a
> stand-alone
> > > application accessing the EJB tier directly couldn't use the
> > > caching, right?
>
[Randy Stafford] I'm sure there must be architectural alternatives.
Why would you want to use EJB only to expose a fine-grained data cache to
clients? One alternative would be to set up a service-based architecture,
implemented with session beans that provide meaningful, problem-domain
related behaviors to clients (see
http://www.netseminar.com/index.cgi?sem_num=198). The method signatures on
the services' interfaces would define the types that clients would work
with, and clients wouldn't need to know or care how the session beans got
the state of the objects returned by those methods. <vendor>If you used
GemStone to implement such an architecture, the services could return
objects cached in GemStone's Persistent Cache Architecture, without having
to O/R map them on the fly.</vendor>
Randy Stafford
Senior Architect
GemStone Professional Services
===========================================================================
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".
