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

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

I think I have not explained myself good enough, and you're answering
just to what I said, not what I meant :-)

The point I'm trying to make is that applications usually let the user
perform transactions on a certain part of the database, and there's
little point to keeping the data from previous transactions around.

For example, imagine a simple app that allows you to delete, insert or
modify the Author's info. The user of such an app will repeatedly look
up an Author, change an attribute or two, commit the change, and start
over again. When the user looks up the second Author, it doesn't make a
lot of sense to keep the first Author's object around, does it? Yes, it
is possible that the application will let the user navigate the second
Author's books, and if the first Author has co-authored a book with the
second, it might also let the user navigate back to the first Author...
but I think it's affordable (and in some cases even desirable) that this
navigation results in the first Author being fetched again from the
database, instead of just fishing a likely stale copy from the cache.


On Thu, 2003-09-25 at 15:40, Sebastien Bigaret wrote:
> In fact, there are two levels of caching.
> 1. Within EC:=20
>   - you fetch an object obj1, and modify it,
>   - then you submit another query, which returns obj1 as well: there,
>     you don't want to override the modification you've made but not
>     saved.

Hmmm... Well, this is the thing. I mean, what are you doing submitting
another query while you still have uncommitted changes? I understand
this is exactly the right behavior if you are traversing a series of
relationships that brings you back to the original table/entity, but my
understanding is that when the program says ec.fetch(...), it is
actually stating that it's done with the results of the last fetch, and
wants to start anew. So if you try to do a fetch while changes are
pending, the EC should either commit the changes (don't like it) or
raise an exception (much better)

> 2. The database's rows cache, held by Database, to which the framework
>    refer for various tasks, such as: building fetched objects, computing
>    the changes that needs to be forwarded to the database, etc.

I'm arguing that for most applications this cache ought to be flushed
with each user-level fetch. I understand that, for single-user
applications, longer-term caching can be a significance performance
boost (although it may, as noted in the documentation, lead to memory
footprint bloat if the application is not restarted regularly). In any
other environment, I feel that the risk of the cache becoming stale
seriously outweights performance concerns.

>   When referring to fetch(), both mechanisms can be triggered:
> 1. -> if the object already exists in the EC, possibly modified, you'll
>       get that one.

I've argued above that fetch() should fail if there are pending changes.

> 2. -> otherwise, the database cache is searched for the row, and if
>       found, that one will be used instead.
> (2.) can be annoying, and that's the situations where this is annoying
>      that 'refresh' will address (and in addition to the default
>      mechanism, it will allow you to do whatever you want through a
>      specific delegate if the object actually changed, just like with
>      optimistic locking)

I agree that optimistic locking could make the long-term caching of rows
workable. It will also, however, make conflicts more likely, because
rows that have been longer in the database cache have a larger
probability of becoming stale.

>   In fact, clearing the cache cannot be the default, just because you'd
>   probably won't rely in the framework to modify the data in your back.
>   Suppose, for example, that when fetching, an previously fetched object
>   has been deleted in the meantime (by an other applications): what you
>   the framework do? Should it take the responsability to delete the
>   object in the EC that fetched the data?

If the database doesn't keep a long-term cache, the call to fetch() will
not return the deleted row. If the deletion takes place after the
fetch(), of course, we'll have to resort to the whole optimistic locking
thing. Come to think of it, I think most of my argument rests upon the
idea that it's desirable to minimize the likelyhood of optimistic
locking conflict occurrence, which sound intuitively right to me, but I
don't have any hard data to back it up.
 =20
>   Not now, but I can make a plan for it, say, this week-end if you wish.

Well, that would be great! I'm trying (and still failing :-) ) to figure
out which module does what in the framework, so an expert opinion on
what would need to be done to get optimistic locking and vertical
mapping working would be a wonderful thing.

> > I must admit I'm kinda skeptic about the notification idea...
> Agreed, just because the modifications could have been made by any
> bash/perl/... script who won't post any modifications ;) Back on the
> notifications, at least they could solve the case where the framework
> runs in a single address space (this is the case in Zope, for example,
> or in any threaded application) and an EC save changes that you'd like
> to see appear in other ECs.

I'm saying that I don't see how notification could solve conflicts even
in a single address space. If both ec1 and ec2 have pending
modifications for obj1, and ec1 commits the change and notifies ec2...
what will ec2 do with its changes?

	Fede