|
|
Posted by David Haynes on 01/07/06 15:49
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-
Navigation:
[Reply to this message]
|