[ZODB-Dev] Savepoints and Shared.DC.ZRDB.TM

[Tim Peters]

[Tim Peters]
>> It's the traceback that's needed here.  You're working too hard ;-)

[Sidnei da Silva]
> Indeed.
>
>   File "C:\Arquivos de programas\Enfold
Server\Products\ATContentTypes\tests\atcttestcase.py", line 258, in
test_migrationKeepsPermissions
>     transaction.savepoint() # subtransaction

Bingo!  That's the root cause of it all.  This isn't Zope code, so I can't
know what it's trying to accomplish.  _Why_ is this code making a savepoint?

Since it throws away the result of the savepoint() call, it's not possible
to roll back to this savepoint's state later.  So the most likely reason is
that it's just "trying to save memory".  In that case, change the code to

    transaction.savepoint(optimistic=True)

and your original problem will go away.

Here from ZODB 3.4.1a5 NEWS:

"""
- (3.4.1a5) Internal uses of subtransactions (transaction ``commit()`` or
  ``abort()`` passing a true argument) were rewritten to use savepoints
  instead.  Application code is strongly encouraged to do this too:
  subtransactions are weaker, will be deprecated soon, and do not mix well
  with savepoints (when you do a subtransaction commit, all current
  savepoints are made unusable).  In general, a subtransaction commit
  done just to free memory can be changed from::

      transaction.commit(1)

  to::

      transaction.savepoint(True)

  That is, make a savepoint, and forget it.  As shown, it's best to pass
  ``True`` for the optional ``optimistic`` argument in this case:  because
  there's no possibility of asking for a rollback later, there's no need
  to insist that all data managers support rollback.

  In rarer cases, a subtransaction commit is followed later by a
  subtransaction abort.  In that case, change the initial::

      transaction.commit(1)

  to::

      sp = transaction.savepoint()

  and in place of the subtransaction abort::

      transaction.abort(1)

  roll back the savepoint instead::

      sp.rollback()
"""