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

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

On Thu, 2003-09-25 at 10:18, Sebastien Bigaret wrote:
> To be precise, an object's row is cached as long as one instance for
> this row is registered in one EC.

OK... So the question WRT cache life seems to be "when does a row get
deregistered from an EC?". It would seem reasonable to think that every
time the EC gets a user-level fetch request (as opposed as a fetch
request due to accessing a fault object), it clears its cache, since the
application now is obviously interested in another set of objects
instead of the ones already in memory. This could create problems if the
application kept references to objects between fetches, but I'd argue
that doing this is a Bad Thing to boot. Should the need arise for this
kind of functionality (kind of hard to imagine, but life is weird), a
method cumulativeFetch() could be added to the EditingContext, which
fetches without clearing the cache first.

> I see the point. This is the current status. Say you have two instances
> (so, two adress spaces) with two ECs, ec1 and ec2. Both query and update
> an object obj1.

Your description matches what I figured, and I like the optimistic
locking idea. Is the implementation of optimistic lockig scheduled any
time soon? Ideas on how much effort it would entail to implement?

> (In fact, as the documentation says and as you noted, we currently also
>  have this problem between two different ECs in the same address space
>  --but this will be solved by delivering notifications to the
>  appropriate objects)

I must admit I'm kinda skeptic about the notification idea... Assume ec1
and ec2 above are in the same address space now. When ec1 commits
changes to object x, it can notify ec2 of this... but what is ec2 going
to do with this information? If ec2 has uncommited changes to x, it has
to resort to the same kind of logic that we'd use in the optimistic lock
case. In the end, thus, the only thing we gain is that we skip a fetch.
Not that this is not important performance-wise, the point I want to
make is that notification alone does not solve the problem, we also need
the optimistic lock resolution for it to work.

> Now if you want two
> different address spaces to be notified of changes made by the other
> before any attempt to save the changes in the db, we would need a more
> general notification mechanism which should be able to broadcast changes
> through the network, but even then, I suspect this is a hard problem to
> solve.

This would be a nightmare, gazillions of things could go wrong, and they
would certainly do so in the worst possible sequence. We don't want to
pursue this.

> Another cleaner solution (and maybe the only one that can be
> guaranteed to be 100% safe) could be to explicitely lock the appropriate
> row before any attempt to modify an object, and to release the lock only
> after changes has been made --this is the so-called pessimistic locking
> strategy.

We could implement this as a method of persistent objects, thus x.lock()
would perform a locking read on the row until the transaction's done or
rolled back. Of course, this means that the programmer will have to take
care of which objects to lock, but such is the fate of the pessimistic
locking programmer :-)

	Fede