units of work are by definition localized to a particular in-process
thread-local session. there is no magical "machine-spanning" unit of
work going on. if you are looking for some kind of "global
database" where all data is always exactly fresh to all processes
everywhere, that would hardly make a dent in the issue of
contention. if you load some data and perform three operations on
it, whoops ! it just changed, you didnt re-SELECT it from the
database on every line of code. even if you did re-SELECT on every
line, the data could *still* change while youre fetching rowsets.
concurrency is handled in two ways: pessimistic locking, and
optimistic locking. With pessimistic, you start a transaction, with
isoliation SERIALIZEABLE. You can do that with SA. With optimistic,
you commit your changes, then insure that they went through OK.
Optimistic concurrency checking simply means when you UPDATE or
DELETE rows, you insure that the returned row count matches
correctly. This is how Hibernate does it, and its how SQLAlchemy
does it.
You have little reason to complain here, I have given you two patches
that will acheive the behavior you are asking for, and if installing
them as switches will bring this conversation to an end so that I can
focus on putting up 0.1.5, then it would all be worth it.
On Mar 26, 2006, at 5:47 PM, Florian Boesch wrote:
As we're down to mutual shouting,
Yes Michael, hibernate may be hugely popular, and I may not know
it, but from
what I hear hibernate scales across a cluster of machines...
How does SA scale across a cluster of machines?
I don't see how this works with SA. I'd be happy if you enlighten
my ways by
simply giving me the directions how to operate SA in order not to
break it when
working with more then one process. Oh pardon, that may be an
overly unrealistic
requirement, silly me!
-------------------------------------------------------
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
