On 11/3/07, Len Popp <[EMAIL PROTECTED]> wrote: > > But isn't the purpose of session replication to allow different > servers to handle the session? If not, what's it for? >
This discussion touches on a bit of philosophy, and a set of design decisions built into the code, and no longer relevant. In this case it's "sticky sessions", a notion that once made some sense, but no longer. There are really only two design points that make sense for sessions: 1) sessions kept in-memory (or on-disk) within a single machine, and 2) sessions kept in an external service (database or specialized store). There are a bunch of intermediate solutions that used to make some sense - before web-oriented databases, before massive scaling, before gigabit local nets, before cheap and insanely fast single-box systems. All the time spent maintaining intermediate solutions removes focus. Java is not losing out to PHP (and the like) due to lack of focus on the present, not inferior technology. Not that I expect the argument to make any headway in this venue, but someone has to raise the issue.
