On 22 Feb 01, at 23:10, Rickard Öberg wrote:
> > A clustered entity would use commit option "C", right?
>
> Not necessarily. It could use A with a decent EJB 2.0 CMP implementation
> that was cluster-aware.
Hi Rickard,
This is an interesting possibility. Does "A" requires serialized
access to an object with a particular key within a home? If so, are
you suggesting a message-passing locking scheme? Let me ask,
then, how synchonization of state would occur between instances.
If also through message passing, the noise of the peer-to-peer
updates would provide an upper limit to the number of cluster
participants, right?
Instead one might use a cache for the database, to which all the
getter and setter methods referred. But then why not make this
cache transactional (i.e. run a database in-memory) and recache
the state in the instance? You still get the benefits of cached data,
but you don't serialize access to the entity, and you don't have to
do the message passing for locking.
> > However, I can envision many
> > scenarios where a stateful session bean might get pinned to a
> > server. Do you think this is what he was reaching for?
>
> Well, stateful sessions can be transferred just as easily between
> servers, in a linearly scaleable way, so that doesn't apply either.
Yes, the most obvious implementation is to have a persistent store
to which you serialize the stateful session bean after each method.
This is sort of "commit option C for stateful session beans." :-)
I can think of other options though. For instance, you could use a
round robin assignment of method invocations to servers on the
cluster for very simple load balancing. You could probably write this
while watching television one evening. For "C" entities and
stateless sessions, the invocations could go to any server
(assuming they were configured identically) and all further calls
within that transaction would be co-located. However, for stateful
session beans (and assuming you are only doing this round-robin
load balancing), you would need to remember which server took the
first invocation, and direct all further invocations on the same
component instance to that same server. This scheme gives only
horizontal scaleability; no high availability or fail-over. Still, it has
the benefit of being quick and simple. (Of course, really you would
want a central way to manage deployments and configurations,
even for this simple scheme. And of course everyone wants at
least high-availability, although most can probably live without fail-
over during a method invocation for a long time--and will have to.
Cause it's hard.)
-Dan
