Ernesto Revilla
2004-06-30 12:33:07 UTC
A message I sent incorrectly to the private mbox of Sébastian.
-------- Mensaje Original --------
Asunto: Re: [Modeling-users] Optimistic Locking
Fecha: Thu, 24 Jun 2004 11:25:15 +0200
De: Ernesto Revilla <***@sicem.biz>
Para: Sebastien Bigaret <***@users.sourceforge.net>
Referencias: <***@sicem.biz>
<***@melimelo.enst-bretagne.fr>
Thanx a lot for your comments. (Perhaps some sentences could go into the
documentation?)
The first thing: is there an easy way to use all attributes of an object
for optimistic locking?
On the other hand, how can I easily simulate optimistic locking
collisions within the same process? (suppose you use ZOPE which has just
one process, but different EditingContext, and want the user to be
warned, when data has been updated by another user?)
Erny
'name' and 'age' are made 'usedForLocking', birthday isn't.
In a EC you fetch a person 'p', manipulate/update it, changing whatever
attributes, than you save changes. At this point (at saveChanges()
time), we make sure that the corresponding row has the same value for
columns 'name' and 'age' (which are marked as 'usedForLocking') than the
value it had *when the object was fetched*.
If values are the same, the updates succeeds, otherwise saveChanges()
fails.
That's the core of it. Optimistic locking is called optimistic because
it makes the assumptions that few conflicts will occur, so the checking
is only made at the last moment --when saving.
- if the corresponding person's birthday has been changed in the db by
an external process, optimistic locking wont notice because the
attribute wasn't used for locking,
- within a single *process*, two ECs will never conflict. This is not
directly related to the way optimistic locking works, rather to the
way the framework handles those updates. When an EC saves its changes,
it broadcasts them to others. Default behaviour will be: when an ec
receives an update for an object, it applies these updates, then
applies back the changes that were made before within this ec.
# NB: p1=p2=Person(name='Cleese', age=42, birthday=None)
p1=ec1.fetch(...)
p2=ec2.fetch(...) # p1, p2 correspond to the same rows
p1.name='John Cleese'
p1.age=24
p2.age=12
ec1.saveChanges()
# now p2.name=='John Cleese', and p2.age==12
Of course you'll have delegates at hand to implement your own
behaviour to handle these cases.
Hopefully this makes things clearer. If not, yell at me ;)
-- Sébastien.
-------- Mensaje Original --------
Asunto: Re: [Modeling-users] Optimistic Locking
Fecha: Thu, 24 Jun 2004 11:25:15 +0200
De: Ernesto Revilla <***@sicem.biz>
Para: Sebastien Bigaret <***@users.sourceforge.net>
Referencias: <***@sicem.biz>
<***@melimelo.enst-bretagne.fr>
Thanx a lot for your comments. (Perhaps some sentences could go into the
documentation?)
The first thing: is there an easy way to use all attributes of an object
for optimistic locking?
On the other hand, how can I easily simulate optimistic locking
collisions within the same process? (suppose you use ZOPE which has just
one process, but different EditingContext, and want the user to be
warned, when data has been updated by another user?)
Erny
Dear Sébastien,
could you explain in some words, and with one example how Optimistic Locking
should work?
Yes ;)could you explain in some words, and with one example how Optimistic Locking
should work?
I saw your commits, but I thought optimistic locking would protect
automatically the whole object from being updated from another
computer. What does it mean an attribute is used for optimistic locking?
That the attribute is checked that it is not updated by another person or
that it is used to check if another person has changed the object?
Say you have obj O (a person) w/ attributes name, age and birthday.automatically the whole object from being updated from another
computer. What does it mean an attribute is used for optimistic locking?
That the attribute is checked that it is not updated by another person or
that it is used to check if another person has changed the object?
'name' and 'age' are made 'usedForLocking', birthday isn't.
In a EC you fetch a person 'p', manipulate/update it, changing whatever
attributes, than you save changes. At this point (at saveChanges()
time), we make sure that the corresponding row has the same value for
columns 'name' and 'age' (which are marked as 'usedForLocking') than the
value it had *when the object was fetched*.
If values are the same, the updates succeeds, otherwise saveChanges()
fails.
That's the core of it. Optimistic locking is called optimistic because
it makes the assumptions that few conflicts will occur, so the checking
is only made at the last moment --when saving.
- if the corresponding person's birthday has been changed in the db by
an external process, optimistic locking wont notice because the
attribute wasn't used for locking,
- within a single *process*, two ECs will never conflict. This is not
directly related to the way optimistic locking works, rather to the
way the framework handles those updates. When an EC saves its changes,
it broadcasts them to others. Default behaviour will be: when an ec
receives an update for an object, it applies these updates, then
applies back the changes that were made before within this ec.
# NB: p1=p2=Person(name='Cleese', age=42, birthday=None)
p1=ec1.fetch(...)
p2=ec2.fetch(...) # p1, p2 correspond to the same rows
p1.name='John Cleese'
p1.age=24
p2.age=12
ec1.saveChanges()
# now p2.name=='John Cleese', and p2.age==12
Of course you'll have delegates at hand to implement your own
behaviour to handle these cases.
Hopefully this makes things clearer. If not, yell at me ;)
-- Sébastien.