Re: [Modeling-users] Optimistic Locking

[Sebastien B. <sbi...@us...>]

Ernesto Revilla <er...@si...> wrote:
> Dear S=E9bastien,
>=20
> could you explain in some words, and with one example how Optimistic Lock=
ing
> should work?

Yes ;)

>=20
> 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.

'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.

Now two remarks:

- 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.

  Example:
    # NB: p1=3Dp2=3DPerson(name=3D'Cleese', age=3D42, birthday=3DNone)
    p1=3Dec1.fetch(...)
    p2=3Dec2.fetch(...)  # p1, p2 correspond to the same rows
=20=20=20=20
    p1.name=3D'John Cleese'
    p1.age=3D24
=20=20=20=20
    p2.age=3D12
=20=20=20=20
    ec1.saveChanges()
    # now p2.name=3D=3D'John Cleese', and p2.age=3D=3D12

  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=E9bastien.