[ZODB-Dev] Thread safety
Dmitry Vasiliev
lists at hlabs.spb.ru
Mon Oct 4 11:53:03 EDT 2004
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
More information about the ZODB-Dev
mailing list