[ZODB-Dev] Transaction is not cleaned up (on abort).

[Tim Peters]

[Syver Enstad]
> ZODB 3.2
>
> I use setLocalTransaction on the Connection which means that the _id
> field is not set.

A code sample would be helpful.  English is ambiguous.  I guess you're
talking about Transaction._id here.

> The code in abort cases on the _id field and refuses to do anything
> to clean up the Transaction object.

That's untrue.  The tail end of Transaction.abort() has:

            del self._objects[:] # Clear registered
            if not subtransaction and freeme:
                if self._id is not None:
                    free_transaction()
            else:
                self._init()

so the most that can be said is that free_transcation() isn't called unless
self._id is set, which means the Transaction instance isn't destroyed in
this case.  For whatever reason, _init() in turn clears the ._id and
._object members, but doesn't clear the .user, .description, _connections,
or ._extension members.  However, it's impossible for me to tell whether the
latter is intentional or accidental, since the latter 4 members use the
"inherit class attribute" trick that's *normally* used only when extremely
worried about memory consumption or (sometimes) speed.  Since those worries
make no-to-little sense here, there's pressure to guess that it's
intentional that _init doesn't clear those members.

Now if there are any docs for the Transaction API in 3.2, I don't know where
they are.  It's dangerous to change anything, since in the absence of docs
people (naturally enough!) work via "I'll try something, and if it doesn't
blow up, that means it must be supported".  So for all I can guess, someone
out there *relies* on that a Transaction created by setLocalTransaction()
retains this crud across abort() calls.  Yes, it seems unlikely, but so has
most other breakage I've seen as the result of a ZODB change.

setLocalTransaction() is deprecated in ZODB 3.3, and Jeremy made a real
effort to document what the heck 3.3's transaction API is.  Alas, that's
still in a partly-unfinished state, and the code is so complicated by
subtransactions, and backward-compatibility hacks, and interactions with
new-in-3.3 TransactionManager objects, that it's not clear to me what it
will do in all cases either.

The *intent* in 3.3 is that you always use a TransactionManager, and, if you
do, a Transaction.abort() in 3.3 always tells the transaction's
TransactionManager to forget the Transaction object, so that a fresh
Transaction object will get created the next time that TransactionManager is
asked for a Transaction.  So what you're seeing in 3.2 wouldn't happen if
3.3 is used as intended.  OTOH, 3.3 supports all old spellings too, and I
don't really know what it will do in all cases then.

> Since I set the user property and use this on commit, it is a bit
> unsettling that this property is carried over into other users
> transactions. No big deal but I maybe someone is interested in it.

Please file a bug report (Zope collector, topic Database).  That's the only
way to get anything on my todo list anymore.
 
FWIW, I'd drop the inherit-class-attr trick for .user, .description,
_connections, and ._extension, and explicitly initialize them in ._init()
instead.  Then your symptom would go away.  I can't guess whether that would
break something, though.