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

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

Federico Heinz <fh...@vi...> wrote:
> Modeling's manual seems to imply that it caches objects in memory
> indefinitely, and raises a few issues of cache consistency among
> EdititingContexts, as well as strategies to work around them.

To be precise, an object's row is cached as long as one instance for
this row is registered in one EC.

> The workarounds, and even the "to-be-implemented clean solution" of
> creating a mechanism for ECs to broadcast changes all seem to assume,
> however, that all ECs reside in the same address space (a Zope server,
> for instance). This need not be the case, though: Imagine a typical
> client-server application that runs in a single address space on the
> client machine. If a machine fetches some rows, and then another one
> changes them, the first machine will never see the changes? It may even
> break them? This doesn't seem like something that can be fixed by
> broadcasting...

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.

  - if ec1 save its changes, ec2 will not see the changes, because it
    has already fetched (and cached) the obj1. We'll need the 'refresh'
    parameter for fetch() to actually the changes,

  - if ec1 saves its changes, then ec2 saves its changes: ec2 will
    actually override the changes made by ec1, and won't even notice
    this.

(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)

Now imagine that optimistic locking is implemented. Optimistic locking
examines the data when they are about to be saved in the db. When the
data in the db differs from the cached one, an error is raised. This
general mechanism can be used to make different address spaces notice
the changes when they save changes (while the 'refresh' parameter of
fetch would enable an EC to discard its cache and its changes, and to
refetch the data).

  Of course, optimistic locking will allow you to supply your own
  delegate to handle such situations. For example, you might decide to
  override the changes for a given entity, or mix the changes observed
  in the db with the ones made on the object, etc.).

This would probably address most problems, I think. 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. 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.

-- S=E9bastien.