Re: [Zope] Trying to trap ConflictError

6 Jul 2006

      ----- Original Message ----- 
From: "Michael Dunstan" <michael.dunstan@gmail.com>
To: "Jonathan" <dev101@magma.ca>
Cc: <zope@zope.org>
Sent: Wednesday, July 05, 2006 5:15 PM
Subject: Re: [Zope] Trying to trap ConflictError
...
TempoaryStorage.py has a few tuning constants. The above error reads
as though RECENTLY_GC_OIDS_LEN is too small for your application. It
may well be that the default tuning of TempoaryStorage does not match
your application very well.
It would be useful to try FileStorage to help decide on where to focus
attention. If FileStorage behaves a lot better then that also suggests
that TempoaryStorage is miss-tuned for your application.
Thanks for the idea Micheal... as a test I changed from TemporaryStorage to 
FileStorage to see if the ConflictErrors would 'go away'.  However, the 
ConflictErrors still occur!  This leads me to believe that the problem is 
not related to TemporaryStorage.

Further investigation led to the discovery that ConflictErrors are being 
raised by TemporaryStorage and FileStorage in the same 'store' routines. 
Here is the relevant code from TemporaryStorage:

    def store(self, oid, serial, data, version, transaction):
        if transaction is not self._transaction:
            raise POSException.StorageTransactionError(self, transaction)
        self._lock_acquire()
        try:
            if self._index.has_key(oid):
                oserial=self._index[oid]
                if serial != oserial:
                    newdata = self.tryToResolveConflict(
                        oid, oserial, serial, data)
                    if not newdata:
                        raise POSException.ConflictError(
                            oid=oid,
                            serials=(oserial, serial),
                            data=data)        # ***** Conflict Error raised 
here ****
                    else:
                        data = newdata
            else:
                oserial = serial
            newserial=self._tid
            self._tmp.append((oid, data))
            return serial == oserial and newserial or ResolvedSerial
        finally:
            self._lock_release()
...
From what I understand from the above code, the error is being raised 
because the oid already exists and the object pointed to by the old oid is 
different from the object pointed to by the new oid, hence the conflict 
error.
I haven't been able to determine how the oid's are generated, other than 
"little-endian 64-bit unsigned integers that will be assigned more or less 
sequentially", but I can't figure out how the same oid is being used twice 
(on the other hand I could be totally off-base as I am really way over my 
head here!).

Once again, any and all ideas, comments, suggestions are greatly 
appreciated!

Jonathan