Perhaps I'm wrong, but it sounds like your algorithm is
1) lock user session
2) process request
3) commit session changes
4) unlock
Many developers new to web development (ab)use sessions to for all their statefulness. I don't mean that as an insult; I did myself. But there are better ways. Fundamentally they involve splitting state up among smaller units than a monolithic "session."
If you give an example of where you're dumping state to the session, I'd be happy to suggest alternatives. :)
On 3/16/06, Florian Boesch <
[EMAIL PROTECTED]> wrote:
I don't understand that statement, can you rephrase?
On an outline, the difficulty to deal with is:
#1 statefull web applications
#2 an array of servers to satisfy a high load of requests
#3 a simplistic apache proxy load balancer (no dns roundrobbin)
I particularly don't understand what serializable (a technical concept
describing the possibility of converting a data-structure to a string), has to
do directly with user expirience.
Quoting Jonathan Ellis < [EMAIL PROTECTED]>:
> I would say that if your application relies on session updates being
> serializable, you need to rethink how you're using sessions. It also makes
> for a lousy user experience.
>
> On 3/15/06, Florian Boesch <[EMAIL PROTECTED]> wrote:
> >
> > How do you solve the problem of sessions represented as rows in database,
> > accessed by an array of web-application servers?
> >
> > The idea is that concurrent write access to session data will happen
> > inevitably,
> > and since throwing an error page at your user everytime it does is not a
> > satisfactory solution you force no errors to happen by locking.
> >
> > It'd be grateful not to do that pattern, and if you see some way which has
> > escaped me please tell me so.
> >
>
> --
> Jonathan Ellis
> http://spyced.blogspot.com
>
--
Jonathan Ellis
http://spyced.blogspot.com
