[ZODB-Dev] Re: BTrees strangeness (was [Zope-dev] Zope 2.X BIGSession problems - blocker - our site dies - need help of experienceZope developer, please)

[Christian Robottom Reis]

On Wed, Mar 03, 2004 at 05:57:41PM -0500, Chris McDonough wrote:
> On Wed, 2004-03-03 at 17:14, Tim Peters wrote:
> > [Chris McDonough]
> > > ...
> > > The _data BTree is of course written to elsewhere in the code
> > >
> > (http://cvs.zope.org/*checkout*/Products/Transience/Transience.py?rev=1.32.1
> > 2.2.2.2&content-type=text/plain)
> > 
> > That code is scary to me -- it talks about threads in the comments, but
> > there's nary a mutex in sight.  If, for example, two threads happen to run
> > _gc() simulateously, what's to stop one from deleting the same keys the
> > other is crawling over?  Since it must be rare for two threads to get into
> > _gc at the same time (but I don't see anything-- like a mutex --that
> > guarantees to stop that), this theory may also fit the "rare and
> > hard-to-reproduce failure" symptom.  It may in fact be safe against thread
> > races, but if it is I don't see how.
> 
> I must misunderstand something.  Given that the code you're talking
> about should raise a ReadConflictError in _gc (I am not using a ZODB
> with MVCC) when two threads try to simultaneously access that data
> structure where one attempts to obtain the results of "keys()" and the
> other is attempting to delete a key, why would I need to protect that
> access with a mutex?  There is no code in Zope AFAIK that employs a

I guess the point being made here is that you shouldn't share the same
persistent object in different threads without locking access to them,
but I wonder if that's not a specific case of "making sure you always
access objects from your transaction" (which in the case of
setLocalTransaction() equates to your connection) or "bad things happen".

Take care,
--
Christian Robottom Reis | http://async.com.br/~kiko/ | [+55 16] 261 2331