yah but heres the thing, under what scenario would a distinct user be
making changes to his or her session in two concurrent processes ?
and if so, (besides WHY?), under what circumstance would there
actually be erroneous behavior ?
this would imply the user has two browsers open and is somehow
submitting both of them so that they occur in exactly the same three-
millisecond window, which has a far less chance of occurring than two
of your servers blowing out their CPUs simultaneously. and if a
user were able to pull such a thing off, if there were no locking at
all, one request would overwrite the other anyway since a row update
is atomic; only one request's action would take effect which is
pretty much what youd expect to see anyway.
Jonathans point has a lot of merit as well (ive seen PJE make the
same point); if you have a big application with multiple servers and
all, its often better to represent user-oriented concepts in a more
explicit and fine-grained way rather than a serialized (the other
kind of serialized) BLOB.
On Mar 16, 2006, at 9:51 AM, Florian Boesch wrote:
I need state mainly for a bunch of authentication related
information, if a user
is logged in and to associated the session with a user (in case he
*is* logged
in).
I don't lock a row on principle, only when a handler gets to do
something that
requires session changes.
Quoting Jonathan Ellis <[EMAIL PROTECTED]>:
No, I was referring to the transaction-oriented meaning of
serializable:
that "any two successfully committed concurrent transactions will
appear to
have executed strictly serially, one after the other." In this
case, by the
brute-force method of actually taking away the ability to process
multiple
requests (from the same user) in parallel. :)
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
-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting
language
that extends applications into web and mobile media. Attend the
live webcast
and join the prime developer group breaking into this new coding
territory!
http://sel.as-us.falkag.net/sel?
cmd=lnk&kid=110944&bid=241720&dat=121642
_______________________________________________
Sqlalchemy-users mailing list
Sqlalchemy-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sqlalchemy-users
-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
_______________________________________________
Sqlalchemy-users mailing list
Sqlalchemy-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sqlalchemy-users
