On Apr 22, 2006, at 3:23 PM, Jesus Cea wrote:

>
> Neil Schemenauer wrote:
>>> So does Durus Storage Server give a "degree 3 isolation"?. That
>>> would be
>>> a very good point.
>>
>> If it doesn't then there is a bug.  Each client remembers the OIDs
>> of objects it has seen during a transaction.  When the client tries
>> to commit, it first receives a set of invalid OIDs from the server
>> (OIDs for objects that have been changed in the DB).  If any of
>> those OIDs have been seen then a conflict error is raised.
>
> Uhmmm. I'm confused.
>
> I think durus will raise a conflict if you have the remotely modified
> object in your cache, EVEN if you didn't accessed that object in
> current
> transaction. Some experiments seems to confirm that idea. I think this
> is an issue to improve in future Durus releases. That is, "false"
> conflicts.

When Neil says "seen" here, he does not mean "accessed".
The loaded_oids set is the set of oids of objects that have had
the state present in memory at some point since the last transaction.

The current Durus policy is conservative, in that it assumes that any
object
that has had the state present at some point since the last
transaction might possibly have
been used to make decisions about what to commit.

You are correct that we could track actual accesses since the
last transaction, and use that to decide if we can avoid a
ConflictError.
I think that would require a little extra work on every
attribute access of a persistent instance.  Would the benefit
be worth the cost?  The answer is not obvious to me.