Bip Thelin typed the following on 04:06 PM 5/6/2001 -0700
>> We also need to answer the question of the request life cycle: the
>> DistributedManager needs to know when a request begins and ends.
>> At the beginning, it must lock the session to prevent other Catalina
>> instances from using it in requests. This can probably just be done
>> in Manager.findSession(). At the end, it must tell the ClusterStore to
>> update the session to other members of the Cluster, and unlock it.
>
>I'm not really sure what you're saying here.
OK, ignore my use of the term ClusterStore - I was melding the
Store and Cluster concepts, but from your comments I see that
we may want to be able to use both in the same setup.
My point is that the Manager/Cluster needs to know when the session is in
use by another instance of Catalina. A locking mechanism must be
implemented by the Cluster (or whatever) to prevent a session from being
used by multiple instances at once. This mechanism will require the
Manager/Cluster system to know when a request begins using
a session, and when it has finished.
>If we say that only one JVM at a time can manipulate a sessions since
>a sessions only belongs to one machine at a time the only time a session
>needs to be replicated is when it's created/changed/destroyed.
Yes. But putting the session into the Cluster at creation time is
unnecessary. It should be put in at the end of the request when
it is created (other Catalina instances can't use it before then
anyway), and updated at the end of each subsequent request.
So we need to have the end of a request call into the Manager
to indicate that the session can be sent to the Cluster and
unlocked for use.
>I'd rather see the replication be implemented in a Manager(i.e.
>DistributedManager or
>maybe change name to MulticastDistributedManager) thus making it possible to
>run any Store with the DistributedManager(i.e. FileStore).
OK, I take your point that extending Store isn't the way to go. But
I don't think we should have a different Manager implementation for
each available distribution mechanism - MulticastDistributedManager,
JMSDistributedManager, JavaSpacesDistributedManager,
JCacheDistributedManager, etc. We should use the same pattern
that Manager/Store uses: a single DistributedManager should be
implemented which is independent of the actual session sharing
mechanism. It should be able to use any implementation of the
Cluster interface.
I'd like to keep the possibility open to implement different distribution
strategies. The strategy we're looking at now is for each instance of the
application to hold copies of every session. An alternative Cluster strategy
would keep the sessions in a central location such as a database: when
a request comes in for a session not found in the current instance, the
Cluster checks the database to see if it's there. This isn't too different
from simply using JDBCStore. A third way is to have just two instances
of the application holding a given session: when instance A creates
the session, the Cluster chooses instance B to hold a backup copy
in case A goes down: if a request comes in to C, B still has it available.
Not that we need to implement all of these, but the architecture we
build now should allow these possibilities and others. Other people
can try out different ideas, and users can choose the system best
suited to their needs.
I'm also not sure about the issues with using persistence and distribution
simultaneously. If we simply use PersistentManager with this distribution
code, each instance will save its own copy of every session to persistent
storage. This might be desirable in some cases - I can see using FileStore,
for instance. But if you use JDBCStore and the Multicast distribution, it's
wasteful - with a 4 server farm, we have 4 copies of each session in the
database. So how should this be addressed? Cluster ought to have some
mechanism which (optionally) ensures that each session is only
persisted once. This may mean having Cluster override Store functionality,
which is why I was thinking of combining the two.
Kief
