[ZODB-Dev] Thread safety

[Dmitry Vasiliev]

Tim Peters wrote:
> [Dmitry Vasiliev]
> ...
> 
>>Is it safe to use code like this:
>>
>>def do_changes():
>>     lock.acquire()
>>     try:
>>         do_obj_changes()
>>         transaction.commit()
>>     finally:
>>         lock.release()
>>
>>?
> 
> If you have only one thread, certainly.  In the absence of knowing
> everything this app is doing, I'm not going to guess.  OTOH, if you do
> reveal everything this app is doing, I won't have time to guess <wink>.  For
> example, as was said last time, each thread should have its own connection
> to the database; there's not enough above to guess whether that's so; the
> only real explanation for thread edge cases I know of in ZODB now is "if you
> use threads exactly the way Zope uses them, that's safe";  as a fine point,
> in ZODB 3.3 you must explicitly discard a transaction that fails, so you at
> least need to defend against commit() failure in the above (threaded or
> not).

For example consider the following code:

def getReply(request):
     lock.acquire()
     try:
         try:
             reply = _getReply(request)
             transaction.commit()
         except:
             log.error("error", exc_info=True)
             transaction.abort()
             reply = None
         return reply
     finally:
         lock.release()

All persistent objects changes only inside _getReply() function. Two 
threads concurrently calls getReply() function...

Is it safe?
Is it possibly/safe to use only one connection object?

-- 
Dmitry Vasiliev (dima at hlabs.spb.ru)
     http://hlabs.spb.ru