Sessions in a load balanced setup

[Balazs Wellisch]

Has anyone here implemented sessions in a load balanced environment using
database storage as a custom session handler? I'd be interested to hear
about your experiences. Upsides, downsides, bugs, troubles, security, etc.

Thanks,
Balazs

[Erwin Moller]

Balazs Wellisch wrote:

Has anyone here implemented sessions in a load balanced environment using
database storage as a custom session handler? I'd be interested to hear
about your experiences. Upsides, downsides, bugs, troubles, security, etc.

Thanks,
Balazs

Hi,

Yes, I did, but not with loadbalancing.
The loadbalancingpart is however irrelevant if you use a database for
sessionstorage, since every session will contact the same database that
stores the sessions.
(If you plan to use more databases for sessionstorage, I give up. :P)

A good place to start is at ZEND:
http://www.zend.com/zend/spotlight/c...lery-wade8.php

That page contains a good example, but without sessionlocking.
I wrote my own that does implement sessionlocking. It is not tested 100%,
but seems to work great so far. If you are interested I'll publish it on
the net, but just start with zend. :-)

Regards,
Erwin Moller

[Balazs Wellisch]

The loadbalancingpart is however irrelevant if you use a database for
sessionstorage, since every session will contact the same database that
stores the sessions.
(If you plan to use more databases for sessionstorage, I give up. :P)
Yeah, the obvious solution is to store all the session information in a
single database. But that would limit the failover capability of the system.
I was thinking about setting up each box with its own copy of the database
and replicate the data between each one. However, I don't think this is a
feasible solution since session info changes all the time and I can't have
the dbs continuously replicate themselves all the time. I suppose I could
use sticky sessions, but I was wondering if there was a better solution out
there.
A good place to start is at ZEND:
http://www.zend.com/zend/spotlight/c...lery-wade8.php

Yes, I looked at Zend and I'm considering investing in their technology.
That page contains a good example, but without sessionlocking.
I wrote my own that does implement sessionlocking. It is not tested 100%,
but seems to work great so far. If you are interested I'll publish it on
the net, but just start with zend. :-)

I'm definitly interested and I'm sure others would benefit from your work as
well. Please let us know if you do decide to publish it!

Thanks,
Balazs

[David Haynes]

Balazs Wellisch wrote:

The loadbalancingpart is however irrelevant if you use a database for
sessionstorage, since every session will contact the same database that
stores the sessions.
(If you plan to use more databases for sessionstorage, I give up. :P)

Yeah, the obvious solution is to store all the session information in a
single database. But that would limit the failover capability of the system.
I was thinking about setting up each box with its own copy of the database
and replicate the data between each one. However, I don't think this is a
feasible solution since session info changes all the time and I can't have
the dbs continuously replicate themselves all the time. I suppose I could
use sticky sessions, but I was wondering if there was a better solution out
there.

There are a number of database technologies that will allow you to set
up replication even in high transaction environments. Oracle's RAS for
example.

Another option is to model the sessions through a persistence object
that uses a database as a backing model. . (Think queries answered from
the persistence object, writes go all the way through to the database,
missing queries are answered from database)

-david-

[Balazs Wellisch]

There are a number of database technologies that will allow you to set
up replication even in high transaction environments. Oracle's RAS for
example.
Sorry, I guess I should've mentioned we have to use MySQL.
Another option is to model the sessions through a persistence object that
uses a database as a backing model. . (Think queries answered from the
persistence object, writes go all the way through to the database, missing
queries are answered from database)

That's a promissing idea. But I still don't see how that will help when a
session jumps from one server to another. Some mechanisim must ensure that
the entire session, along with whatever variables that session contains, is
current on each server. So, if a session gets created on server A and then
it jumps to server B it would have to already exist there. Otherwise the
user could have their session reset a number of times during their visit.
Replication is the only tool I know of that can accomplish this. Any
thoughts?

Balazs

[Peter Fox]

Following on from Balazs Wellisch's message. . .

Yeah, the obvious solution is to store all the session information in a
single database. But that would limit the failover capability of the system.
I was thinking about setting up each box with its own copy of the database
and replicate the data between each one. However, I don't think this is a
feasible solution since session info changes all the time and I can't have
the dbs continuously replicate themselves all the time. I suppose I could
use sticky sessions, but I was wondering if there was a better solution out
there.

[The first time I've ever considered this issue so don't take it as
tried-n-tested]

Surely /each box/ doesn't need /its own/ database. If the objective is
to allow some failure to be brushed-off then two databases with
replication should do the trick when you need both DBs to be u/s before
the system fails. Also you would operate normally on a single DB with
the other in standby - as you'd be operating presumably with your main
DB.

Q: What happens if I log into your site twice from my Tabbed browser.
Might I operate as the same session but hitting different servers?[1]
If so what exploit could I use to load a trolley on both screens, buy on
one and decide not to buy on the other and have the cancel overwrite the
buy but not before the goods were authorised for dispatch. [Not a 'you
mustn't do it!, but a GLB-ism]

[1] Even if by hacking the browser (but more likely by cutting and
pasting ?SID=123456 from one tab to the other) - could be worth a lot of
money.
--
PETER FOX Not the same since the icecream business was liquidated
pe******@eminent.demon.co.uk.not.this.bit.no.html
2 Tees Close, Witham, Essex.
Gravity beer in Essex <http://www.eminent.demon.co.uk>

[David Haynes]

Balazs Wellisch wrote:

There are a number of database technologies that will allow you to set
up replication even in high transaction environments. Oracle's RAS for
example.

Sorry, I guess I should've mentioned we have to use MySQL.

Oracle RAS was an example. There may be an equivalent for MySQL.
(probably a commercial product...)

Another option is to model the sessions through a persistence object that
uses a database as a backing model. . (Think queries answered from the
persistence object, writes go all the way through to the database, missing
queries are answered from database)

That's a promissing idea. But I still don't see how that will help when a
session jumps from one server to another. Some mechanisim must ensure that
the entire session, along with whatever variables that session contains, is
current on each server. So, if a session gets created on server A and then
it jumps to server B it would have to already exist there. Otherwise the
user could have their session reset a number of times during their visit.
Replication is the only tool I know of that can accomplish this. Any
thoughts?

Balazs

Let me break it down.
1. There is one database which is replicated across two instances each
on its own server (i.e. fault tolerance for database and database
servers) The database access object has one access method which
understands which database is primary and which is secondary or the
database handles this for you. Some schemes will also alternate queries
between the two instances.
2. Each web service is on its own server and instantiates a persistence
object which talks to the database.
3. As a user session progresses, each new session value is stored in the
local persistence object (i.e. the one on the server that the browser is
currently talking to) *and* the value is also written through to the
database. This used to be called 'write-through caching'.
4. If the user requests session information which is already in the
persistence object, it is simply handed back.
5. If the user requests session information which is not already in the
persistence object, the database is queried for the [session:tag:value]
which is then stored in the local persistence object.
6. The only place this gets tricky is if you need what used to be known
as an 'atomic cache invalidate' (i.e. you want to guarantee the value of
a session variable across all persistence objects or, in other words,
force all persistence objects to refresh their local copies of the
session data from the database). If you need this, you will have to work
out some sort of intra-persistence object protocol (via the database
most likely but the network also works) to indicate that a
[session:tag:value] tuple should be refreshed from the database even
though it is in the local persistence store.

Clearer?
-david-

[Balazs Wellisch]

> Oracle RAS was an example. There may be an equivalent for MySQL. (probably

a commercial product...)
Yes, I guess my next step is to find out what MySQL has to offer in this
regrad.
1. There is one database which is replicated across two instances each on
its own server (i.e. fault tolerance for database and database servers)
The database access object has one access method which understands which
database is primary and which is secondary or the database handles this
for you. Some schemes will also alternate queries between the two
instances.
2. Each web service is on its own server and instantiates a persistence
object which talks to the database.
3. As a user session progresses, each new session value is stored in the
local persistence object (i.e. the one on the server that the browser is
currently talking to) *and* the value is also written through to the
database. This used to be called 'write-through caching'.
4. If the user requests session information which is already in the
persistence object, it is simply handed back.
5. If the user requests session information which is not already in the
persistence object, the database is queried for the [session:tag:value]
which is then stored in the local persistence object.
6. The only place this gets tricky is if you need what used to be known as
an 'atomic cache invalidate' (i.e. you want to guarantee the value of a
session variable across all persistence objects or, in other words, force
all persistence objects to refresh their local copies of the session data
from the database). If you need this, you will have to work out some sort
of intra-persistence object protocol (via the database most likely but the
network also works) to indicate that a [session:tag:value] tuple should be
refreshed from the database even though it is in the local persistence
store.

Clearer?
-david-

I'm with you. Thank you for the advice!

Balazs

[Balazs Wellisch]

> Surely /each box/ doesn't need /its own/ database. If the objective is to

allow some failure to be brushed-off then two databases with replication
should do the trick when you need both DBs to be u/s before the system
fails. Also you would operate normally on a single DB with the other in
standby - as you'd be operating presumably with your main DB.
That is an option. However, I was thinking that from a maintenance
standpoint it would be easier to clone a system completely. That way I would
have a bunch of inexpensive, hot pluggable machines. This would give me
infinite scalability for a small initial investment and minimal
configuration to deal with as the number of systems increases. The database
is not going to be huge. Otherwise, you're right, it would probably make
more sense to go with your suggested setup of two separate databases.
Q: What happens if I log into your site twice from my Tabbed browser.
Might I operate as the same session but hitting different servers?[1] If
so what exploit could I use to load a trolley on both screens, buy on one
and decide not to buy on the other and have the cancel overwrite the buy
but not before the goods were authorised for dispatch. [Not a 'you mustn't
do it!, but a GLB-ism]

[1] Even if by hacking the browser (but more likely by cutting and pasting
?SID=123456 from one tab to the other) - could be worth a lot of money.

This is more of an issue of security that I would have to deal with no
matter what. I think with URL based session ids turned off, session finger
prints and other security measures this problem can be eliminated.

Thanks for your advice.
Balazs