It's hard to follow what you're doing. It might help if you posted
*your* code, rather than the ZODB code.

But first, I suspect, as you do, that the C++ threads aren't playing
nice with the Python per-thread transaction management.

I suggest giving each connection it's own transaction manager:

  >>> conn =
  >>> ... do some things
  >>> conn.transaction_manager.commit()

As long only one thread is accessing the connection at a time, you
should be OK.


2010/6/8 Alberto Casado Martín <>:
> Sorry again , think i didn't confirm the inscription before sending the
> mail... :)
> 2010/6/8 Alberto Casado <>
>> I forgot  one step in the code, sorry.
>> El 08/06/2010, a las 02:08, Alberto Casado escribió:
>> Hi all
>> I don't know if this is the list where I have to ask, if isn't it, sorry.
>> In the last weeks I am having a lot of problems trying to figure out how
>> ZODB should interact with a multithread app.
>> In short,  basically the App is a GUI that receives data from sensors. It
>> is a distributed system, built with  omniORB, when the info comes from the
>> sensors it is store in ZODB and it is shown  in a GUI where can be modify by
>> an operator (human) and this changes are commited to ZODB and send back to
>> the sensor.
>> I have a connection for each thread, due to that  sometimes the thread is
>> created in c++, I don't have the control of the pool. But i am pretty sure
>> that before any change is done, I create a new connection for this thread
>> (and also getting the root object).
>> Almost every  time i try to commit to ZODB I have an error
>> Duplicate tpc_begin calls for same transaction
>> I have observed that when info comes from the sensors (one call, one
>> thread , I am dealing only with one message now) and I update the data ,
>> different objects (ZODB persistent classes), these  distinct objects are
>> registered in several connections, so when I try to commit them, always end
>> up in the same error...
>> As I can see in the code, the first time goes fine, but the second is
>> going to fail  always, because the transaction is assigned to the storage.
>> from
>> def _commitResources(self):
>>         # Execute the two-phase commit protocol.
>>         L = list(self._resources)
>>         L.sort(rm_cmp)
>>         try:
>>             for rm in L:
>>                 rm.tpc_begin(self)------- tpc_begin always with self.
>>             for rm in L:
>>                 rm.commit(self)
>>                 self.log.debug("commit %r" % rm)
>>             for rm in L:
>>                 rm.tpc_vote(self)
>>                 self._voted[id(rm)] = True
>> from
>> def tpc_begin(self, transaction):
>>         """Begin commit of a transaction, starting the two-phase
>> commit."""
>>         self._modified = []
>>         # _creating is a list of oids of new objects, which is used to
>>         # remove them from the cache if a transaction aborts.
>>         self._creating.clear()
>>         self._normal_storage.tpc_begin(transaction)
>> From
>> def tpc_begin(self, transaction, tid=None, status=' '):
>>         if self._is_read_only:
>>             raise POSException.ReadOnlyError()
>>         self._lock_acquire()
>>         try:
>>             if self._transaction is transaction:------------ the fisrt
>> time goes fine,but the second always fail
>>                 raise POSException.StorageTransactionError(
>>                     "Duplicate tpc_begin calls for same transaction")
>>             self._lock_release()
>>             self._commit_lock_acquire()
>>             self._lock_acquire()
>>             self._transaction = transaction------------
>>             self._clear_temp()
>> This is killing me, I don't know if it is an error registering
>> modifications that are happening in one thread, to several connections and I
>> dont know why this is happening...
>> I someone can give me some clue...
>> BR.
>> Alberto.
>> PD: sorry for my English.
> _______________________________________________
> For more information about ZODB, see the ZODB Wiki:
> ZODB-Dev mailing list  -

Jim Fulton
For more information about ZODB, see the ZODB Wiki:

ZODB-Dev mailing list  -

Reply via email to