[ZODB-Dev] Thread safety

[Dmitry Vasiliev]

Tim Peters wrote:
>> [Dmitry Vasiliev]
>>The only problem with the code above that it should use
>>transaction.TransactionManager instead of default
>>transaction.ThreadTransactionManager.
> 
> 
> Unclear.  TransactionManager didn't exist before ZODB 3.3.  If you're
> determined to muck with threads in this way in 3.3, I'd certainly recommend
> creating an instance of TransactionManager, passing it to DB.open(), and
> making all your explicit transaction operations through that same instance;
> before 3.3, I'd recommend using the setLocalTransaction() method instead,
> immediately after opening a Connection.

I use ZODB 3.3 like this:

class DataBase(object):

     def __init__(self, db):
         self._db = db
         self._txn_mgr = TransactionManager()
         self._conn = db.open(txn_mgr=self._txn_mgr)

     def commit(self):
         self._txn_mgr.get().commit()

     def abort(self):
         self._txn_mgr.get().abort()

     def close(self):
         self._conn.close()
         self._db.close()

     ...

 >> [Dmitry Vasiliev]
>>Quote from ZODB.Connection.Connection docstring talk about this use case:
> 
> 
> Not really.  It's unclear what it's talking about, exactly, but you want it
> to cover your specific use case so you're inclined to read it that way
> <wink>.
> 
> 
>>"""
>>     Synchronization
>>     ---------------
>>
>>     A Connection instance is not thread-safe.  It is designed to
>>     support a thread model where each thread has its own transaction.
>>     If an application has more than one thread that uses the
>>     connection or the transaction the connection is registered with,
>>     the application should provide locking.
>>"""
> 
> I'll translate:
> 
>     A Connection instance is not thread-safe.  It is designed to
>     support a thread model where each thread has its own transaction,
>     exactly like Zope does.  If you don't use threads in this way,
>     it's hard to guess what will happen, but you're at least going
>     to need locking of some sort or it will certainly fail horribly.
>     If we knew exactly what needed to be protected by locks, and when,
>     we would have explained that instead of giving vague "provide
>     locking" advice.

:-)

> IOW, you'll try something, and it will work or it won't.  If it doesn't
> work, the resolution will be that you didn't "provide locking" at a correct
> time in a correct way.  That's OK by me <wink>.

Ok, but if "it doesn't work" the debugging will be nightmare... :-)

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