Deprecation problem and ConnectionStateError,
was: Re: [ZODB-Dev] Span transaction over several threads
Diez Roggisch
d.roggisch at ehotel.de
Thu Sep 9 17:31:34 EDT 2004
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
More information about the ZODB-Dev
mailing list