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.