Deprecation problem and ConnectionStateError, was: Re: [ZODB-Dev] Span transaction over several threads

[Diez Roggisch]

Hi,

> 3.3 currently supplies two transaction manager classes, which you can use
> or not, depending on what you want -- or you can write your own transaction
> manager (a possibility that didn't exist before 3.3).  The default is
> ThreadTransactionManager, which associates a transaction per thread.  The
> other is TransactionManager, which has no knowledge of threads.  The
> example in NEWS.txt uses the latter.  It supplies the same semantics as
> 3.2's setLocalTransaction(), but via using an explicit transaction manager
> instead of dedicated, special-case methods in Connection (and the latter
> methods are deprecated now).
>
> > Which is a desaster to my usecase, as concurring accesses to the corba
> > service would kick out each others transaction.
>
> Sorry, I didn't understand your use case.  But if you thought
> setLocalTransaction() worked for it, then passing a
> transaction.TransactionManager instance should work the same way.

In my use-case, the corba server has several worker threads. A client has some 
sort of ApplicationContext, which actually makes the transactional logic 
(begin, commit, rollback) accessable for the client.

Now subsequent calls to the corba server that shall belong to one transaction 
failed before I putted the setLocalTransaction in place. The reason was that 
some internal objects used for synchronization/transaction management 
couldn't be released, as the current thread on commit/rollback was different 
from the one that was in charge when the transaction began - see my first 
post on transaction spanning for the detailed error message.

If I understood the NEWS.txt correctly, the other TM that I use will instead 
of associating the sync-stuff thread-local associate it globally to all 
threads. But I fear that this could cause trouble, depending on how that is 
accomplished - on a per-connection-base for all threads, or for all 
connections for all threads. But to toy around with that is exactly the 
reason I started using tests, so hopefully I get some definite answers to 
that soon. Be sure I'll be back if trouble arises :)

> tearDown() should always get called, regardless of whether a test raises an
> exception.  I'm not sure what you mean by "an assertion fails" -- Python
> assert *statements* should never be used in tests (although Zope's tests
> aren't the best example of this rule <wink>).  Instead of

I didn't use assert as statement, I used self.assert_(...)

But the problem has been solved - I accidentially introduced an error in the 
setUp method, and that caused an assertion in there to fail. And of course 
the tearDown didn't get called if the setUp fails. My bad  - thanks for your 
useful tips anyway.

Regards,

Diez