geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alex Blewitt <>
Subject Re: Web Clustering
Date Sun, 17 Aug 2003 20:17:38 GMT
>>> shared-store - many nodes storing their state in a common service.
>> Seems like a fairly good definition; I was using the term 'store' to 
>> imply something like a database or other external product at the back 
>> end.
> try to get away from concrete implementations at this stage - just 
> think of a store as 'storage', whether that is a DB, a shared 
> filesystem, a specialist  server or whatever, should be irrelevant at 
> this design level. Jetty's distributable session manager simply has an 
> AbstractStore class which can be implemented on any form of storage 
> that you choose.

Yes, I think this kind of interface would be very useful. That way, the 
storage layer could be abstracted away to whatever was desired (in 
fact, IMHO, it could be used regardless of whether it was backed by a 
DB, or in-memory, or even whether it supported replication :-)

> The point about shared store is that there is ONE store (conceptually, 
> although it may be clustered, hot-standby-ed or whatever) and everyone 
> (cluster or partition) shares it.

Sounds reasonable.

>>> replication - each node storing copies of it's state somewhere 
>>> off-node (probably not in the same place as all the other nodes). I 
>>> am suggesting that this 'other-place' is on the back of another 
>>> web-container.
>> There's a difference between having the current state in memory, and 
>> replicating it off-node, to only loading the state into memory 
>> dynamically from a backend database. Further, the term replication is 
>> used in databases as well which could add to the confusion.
> 'replication' is not my coinage, but usage in current literature.
> Shared store and replication do, of course, share common 
> functionality. What differentiates (in my mind) replication is that 
> the session storage functionality resides in the same processes as the 
> session creation/consumption. (So you can think of replication as a 
> specific subset of shared store of you like).

I think that there is a distinction to be made between (a) storage 
in-process and (b) replication of store's contents across different 

For example, replication (to me) often comes up with a shared database, 
where each client conceptually looks at one database, but the database 
does replication across different machines.

So it's confusing (for me) to use the term 'replication' to directly 
relate to in-process-storage.

Of course, I do understand the purpose of replicating sessions across 
different nodes, but IMHO there could be better terms to differentiate 
between (a) in-process vs out-of-process storage, and (b) 
replication/proxying of that data to other nodes. You can have:

o in-process, non-replicated storage for development machines
o out-of-process non-replicated storage for two servers speaking to the 
same DB/JMS/Whatever
o out-of-process replicated storage for a cluster of machines talking 
to a (smaller) cluster of database servers, with the DB/JMS/Whatever 
doing replication, and
o in-process replicated storage using the solution you're proposing.

>> Alex.
> I've had a look and, if you don't beat me to it, will add my thoughts 
> when I have a bit more time.

I'll let you put your own thoughts on there; if you and I can convince 
each other that we know what we're talking about, we've got a much 
better chance of being able to convince others of that, too :-)


View raw message