modeling-users

[Modeling-users] Optimistic Locking

[Ernesto R. <er...@si...>]

I agree with Fede that this should be one of the priorities, cause it =
has so many positive effects:
we can let modeling run in a 'heavy client', although this is not an =
approach that I like, because I want the business logic on the server, =
but....
we can do load balancing with more servers, we can use different editing =
contexts for each session, as already done with Zope, and detect easily =
any update collisions. Each application should handle collisions on it's =
own way.

I don't agree with Heinz on the fetch problem, because:
* the probability we hack on the same data over and over again is very =
high. This is a matter of natural work.
* it may be normal to fetch the objects in several steps, although it is =
more probable to get the objects through object traversal.
* as S=E9bastien said, you can use ec.dispose()
* we definetly need some refresh mechanism. I don't know if the strategy =
to only reread data if write collisions are detected is better than =
doing a refresh on some fetch. Just a comment: I think ZEO (Zope =
Enterprise Objects) use notifications to invalid objects, yes, the =
server sends messages to the client to invalidate data. This does not =
consume much bandwith as there are not many objects that change. (But =
this may not be the same context in RDBMS.)

Erny

[Modeling-users] Optimistic Locking

[Ernesto R. <er...@si...>]

Dear Sébastien,

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?

With best regards,
Erny

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.

Re: [Modeling-users] Optimistic Locking

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

"Ernesto Revilla" <er...@si...> wrote:
> I agree with Fede that this should be one of the priorities, cause it has=
 so many positive effects:
> we can let modeling run in a 'heavy client', although this is not an appr=
oach that I like, because I want the business logic on the server, but....
> we can do load balancing with more servers, we can use different editing =
contexts for each session, as already done with Zope, and detect easily any=
 update collisions. Each application should handle collisions on it's own w=
ay.

  Absolutely, and I'll definitely post a plan for it this we.=20

> I don't agree with Heinz on the fetch problem, because:
> * the probability we hack on the same data over and over again is very hi=
gh. This is a matter of natural work.
> * it may be normal to fetch the objects in several steps, although it is =
more probable to get the objects through object traversal.
> * as S=E9bastien said, you can use ec.dispose()
> * we definetly need some refresh mechanism. I don't know if the strategy =
to only reread data if write collisions are detected is better than doing a=
 refresh on some fetch. Just a comment: I think ZEO (Zope Enterprise Object=
s) use notifications to invalid objects, yes, the server sends messages to =
the client to invalidate data. This does not consume much bandwith as there=
 are not many objects that change. (But this may not be the same context in=
 RDBMS.)

  I think we now all agree that both points of view should be
  possible. Now for the inter-process communication/notification, that's
  yet another feature that should be studied on its own --if you have
  more details about ZEO, I'm interested.

-- S=E9bastien.

Re: [Modeling-users] Optimistic Locking

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

Sebastien Bigaret <sbi...@us...> wrote:
> "Ernesto Revilla" <er...@si...> wrote:
> > I agree with Fede that this should be one of the priorities, cause it h=
as so many positive effects:
> > we can let modeling run in a 'heavy client', although this is not an ap=
proach that I like, because I want the business logic on the server, but....
> > we can do load balancing with more servers, we can use different editin=
g contexts for each session, as already done with Zope, and detect easily a=
ny update collisions. Each application should handle collisions on it's own=
 way.
>=20
>   Absolutely, and I'll definitely post a plan for it this we.=20

I thought I'd have the time, but unfortunately I did not. That will be
for the next few days, sorry for the delay.

-- S=E9bastien.

Re: [Modeling-users] Optimistic Locking

[Federico H. <fh...@vi...>]

On Fri, 2003-09-26 at 07:05, Ernesto Revilla wrote:
> I agree with Fede that this should be one of the priorities, cause it
> has so many positive effects:
> we can let modeling run in a 'heavy client', although this is not an
> approach that I like, because I want the business logic on the server,
> but....
> we can do load balancing with more servers, we can use different
> editing contexts for each session, as already done with Zope, and
> detect easily any update collisions. Each application should handle
> collisions on it's own way.

I agree that "heavy client" is not generally the way to go. However, if
you solve that problem in a clean way, then you *know* everything else
will work as well, and some interesting applications (like the load
balancing you mention) become much easier.

> I don't agree with Heinz on the fetch problem, because:

As to this moment, I'm afraid I don't agree with Heinz either :-)

	Fede