On Jul 26, 2006, at 2:40 PM, Steve Strassmann wrote:

> I am using Quixote(2.4), scgi server (1.10) and durus (3.4.1). If I
> run with
> max_children more than 1 I get ReadConflict. I already trap
> conflict errors
> in the commit_changes method (and simply call connection.abort())
> and all the
> messages are comming up within the start_request routine within
> Quixote. The
> problem is largely that all the images and javascript file requests
> arrive
> thick and fast, each one triggering access time updates on the
> session.
>
> I can reduce the impact by moving the application into a separate
> path and
> setting the session path accordingly. I might modify quixote to
> update the
> access time when it commits. However, these things reduce the
> potential
> impact and do not necessarily remove the problem.
>
> Forgive me if I have misunderstood something, but my understanding
> of what is
> going on centers on durus and conflict handling.
>
> The client.invalid set in the storage server records a list of oids
> that have
> been committed on behalf of other clients. If my client reads (or,
> in version
> 3.4 makes a change to) an oid in this list then a ReadConflict is
> generated.
>
> So, I have two processes, A and B. Process A reads, updates and
> commits oid 1.
> This places '1' in the invalid list relating to process B. When
> process B
> comes to read oid 1, after process A has finished and before anyone
> else can
> get in and clear the invalid list, it triggers a ReadConflict. If I
> have one
> process and attempt to read oid 1 twice in succession there is no
> error.
>

Does process B call abort() at the beginning of the request-
processing code?
If not, that would help, since it flushes the invalidations.

Do you have some way to avoid writing the access time on the session on
every hit?  Is your Session.ACCESS_TIME_RESOLUTION high enough?

> If I have it right, it looks as though two sequential read/modify/
> write cycles
> on the same oid can cause an error in one circumstance and not in
> the other.
>
> In practice, I am only interested in what someone else is doing if
> I have
> already read the data and I now want to commit a change.

That seems reasonable.   We can't do this at the moment because
Durus can't provide anything but the most current version of each
instance,
and we must raise a conflict if that new version is inconsistent with
instances that you are currently using.  This is the basic motivation
behind MVCC, which Durus does not currently provide.  I think we
will provide MVCC in Durus 4.0.

> This suggests to me
> that there ought to be a _sync when the oid is loaded (and throw
> away the
> invalid list) but the comments in get_stored_pickle seem to suggest
> that this
> has aleady been done.

You can't ever just throw away the invalid list.  Your decisions
about what to
load and what to commit depend on what you look at.  If you have looked
at anything that is invalid at the time of the commit, we must not
let the
commit be completed.  There is a kind of _sync when you load an object:
the server tells you if the object you are trying to load has been
changed
since the time of your last sync abort.

> What have I not understood?

Not sure.