geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jules Gosnell <>
Subject Re: Web Clustering
Date Sun, 17 Aug 2003 18:55:20 GMT
Alex Blewitt wrote:

> On Sunday, Aug 17, 2003, at 16:35 Europe/London, Jules Gosnell wrote:
>> Alex,
>> we seem to be using the same terms to mean very different things and 
>> this is leading to confusion.
>> I'll go first:
>> 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.

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.

> Since I'm presuming that in order for this to occur, there has to be a 
> shared-store (and will all implementations will be a shared-store) 
> then can we come up with a name for 
> sessions-stored-in-a-backend-system? Or is that what you mean by 
> shared-store? (I.e. do you consider your 'replication' model to be a 
> 'shared store' because to me, it reads like it does.)
>> 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).

Adding this constraint allows replication based clusters to avoid one of 
the round trips to a shared store that would be associated with reading 
and writing to a session. The read is cheap, because the data is already 
on-node. The write is as expensive as you would expect writing to a 
shared store to be, because you have to ship the data off-node in case 
of catastrophic failure.

> Replicated sessions sounds like a good name for this concept, though.
>> The implementation of the storage in either situation is not 
>> specified - I'm doing a logical design.
>> Affinity is load-balancing policy, which allows you to optimise 
>> caching (and possibly forget about session distribution entirely, if 
>> you can live with SPoFs), because you can predict where subsequent 
>> requests for a session will fall.
> Yes, that's the general idea I had of affinity. 


This thread is about <distributable/> webapps, so I shall only be 
discussing affinity as a way of optimising the work done in distributing 
a session, although I am quite aware that affinity, by itself, may be 
seen as an alternative to the use of <distributable/> webapps.

>> How do these compare to your definitions ?
> Pretty well, I think; the only thing that I'm not sure is whether 
> 'shared-store' covers your concept of 'replication' or not (since that 
> is, by definition, a common service across nodes ...)
>> Once we talk the same language, we can go forward :-)
> I tried to put those definititions on Wiki (or at least, what I 
> thought they were). I'm pretty sure we've got the same ideas of 
> concepts; if you want to edit the wiki and put '.. or Xxxx ' in the 
> section titles then once we've got the ideas mapped to what we call 
> them, we're in a much better position :-)
> 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.



 * Jules Gosnell
 * Partner
 * Core Developers Network (Europe)

View raw message