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.
Good.
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 :-)
http://nagoya.apache.org/wiki/apachewiki.cgi?ApacheJ2EE/Clustering
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
-- /************************************* * Jules Gosnell * Partner * Core Developers Network (Europe) * http://www.coredevelopers.net *************************************/
