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

[Tim Peters]

>> See NEWS.txt, under the "ZODB3 3.3 alpha 3" section.  In short, you
>> create an instance of transaction.TransactionManager and pass it to
>> open().  Hmm! The example there is wrong:  TransactionManager doesn't
>> have a commit()

[Diez Roggisch]
> Ok, I read that. From what I understand, either a Transaction is attached
> to the current thread, or to all threads.

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.

> I'm currently in the process of writing tests, so I can't verify that,
> but hopefully soon I can.
>
> Tim, as you are somebody more familiar with test-driven developement and
> the unittest-module, I've got a somewhat offtopic question on that:
>
> For testing, I've got to spawn a corba server. I do that in setUp of my
> test. I kill the server in the tearDown-method. That works fine, unless
> an assertion fails - then the tearDown-method seems not to be called. Is
> that the desired behaviour, and if yes is there another callback or
> something similar that I can use to kill the server?

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

    assert whatever

in a unittest you should do

    self.assert_(whatever)

or (if you can stomach the spelling)

    self.failUnless(whatever)

Any way of spelling it should have no effect on whether tearDown() gets
called, though.

When working with any new framework (unittest included), it's wise to start
small.  For example, run this:

"""
import unittest

class MyTest(unittest.TestCase):
    def setUp(self):
        print "setting up"

    def tearDown(self):
        print "tearing down"

    def checkFail(self):
        assert 0, "oops"

suite = unittest.makeSuite(MyTest, "check")
unittest.TextTestRunner().run(suite)
"""

You'll see that setUp and tearDown are both called, and that the test fails
via a failing assert.  Since that works, and what you're doing doesn't, look
for the difference between them <wink>.