Re: [Modeling-users] Re: Consistency among different processes?

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

On Thu, 2003-09-25 at 19:08, Sebastien Bigaret wrote:
>   If you want this, you can simply ec.dispose() after you've done with
>   the changes, and the objects will be invalidated and the corresponding
>   cached rows will be removed (I assume here that you only have one EC
>   at a time). This way, you'll get the exact behaviour you're asking
>   for.

OK, sold! :-)

> Okay, I'll try hard to make this happen this week-end, then. BTW, I know
> there should be documentation for the framework's architecture.
> Hopefully this will be done one day, but the todo list is sooo long...

Sounds familiar... :-) We'll have to communicate stuff internally, so
we're likely to produce *some* form of representation of the
architecture. If we do, we'll definitely share it.

> You can think about these notifications as a mean to provide a specific
> and application-specific behaviour for minimizing failures under
> optimistic locking strategies, at least when in a single
> address-space.

It sounds to me that what you'd be getting is more like early
announcement that a conflict is coming, but the conflict-resolution
logic will still have to be there.

> Moreover, these notifications are really needed if for
> any reason you ''choose'' the no-locking policy (which is the only
> supported policy by now, and the reason why the User's Guide details the
> problem when using one EC per session).

This is, of course, true. But if we're talking priorities, I think
optimistic locking would be first, because you'll pretty much need its
infrastructure to resolve the conflict you've just been informed of.

>   Does all this make sense wrt your own claims & requirements?

It does. And I'm not making claims or requiring things... I'm just
exploring possibilities.

By the way, I *like* this whole exchange! Makes me feel good about
working with you.

	Fede