Hi Jim,

I was wondering if we could revisit the savepoint support for
transaction before the next transaction version bump for py3
compatibility. Savepoint release is useful for relational database
users who have long running transactions with many (hundreds or
thousands) of savepoints and need to free database resources. In
zope.sqlalchemy they are mapped to a SQLAlchemy nested transaction
commit, which at least for PostgreSQL maps onto a RELEASE SAVEPOINT.

A savepoint.release() will invalidate any subsequent savepoints for
consistency with the behaviour of the major RDBMSs.

Here is the branch changeset:

I will update this once Chris's py3 branch is merged to ensure py3


On 9 June 2010 19:00, Jim Fulton <j...@zope.com> wrote:
> Thanks! I'll review and presumably merge this as soon as I can.
> JIm
> On Mon, Jun 7, 2010 at 12:45 PM, Laurence Rowe <l...@lrowe.co.uk> wrote:
>> Hi Jim,
>> I've created a new branch for my savepoint release changes following
>> the 1.1 release here:
>>  svn+ssh://svn.zope.org/repos/main/transaction/branches/elro-savepoint-release-1.1
>> This does seem to be a real requirement, as I've had another request
>> to provide this functionality for zope.sqlalchemy - when a large
>> number of savepoints are used, the eventual commit can lead to a
>> `RuntimeError: maximum recursion depth exceeded` in SQLAlchemy as it
>> attempts to unroll its nested substransactions.
>> Laurence
>> On 17 January 2010 15:45, Laurence Rowe <l...@lrowe.co.uk> wrote:
>>> 2010/1/17 Jim Fulton <j...@zope.com>:
>>>> On Sat, Jan 16, 2010 at 1:03 PM, Laurence Rowe <l...@lrowe.co.uk> wrote:
>>>>> I've had a request to add savepoint release support to zope.sqlalchemy
>>>>> as some databases seem to limit the number of savepoints in a
>>>>> transaction.
>>>>> I've added this in a branch of transaction here:
>>>>> svn+ssh://svn.zope.org/repos/main/transaction/branches/elro-savepoint-release
>>>>> >From the changelog:
>>>>> * Add support for savepoint.release(). Some databases only support a 
>>>>> limited
>>>>>  number of savepoints or subtransactions, this provides an opportunity 
>>>>> for a
>>>>>  data manager to free those resources.
>>>>> * Rename InvalidSavepointRollbackError to InvalidSavepointError (BBB 
>>>>> provided.)
>>>>> If there are no objections, I shall merge this to trunk.
>>>> I'll review and merge.
>>> Great, thanks!
>>>> What does it mean to "release" a savepoint? How is this different from 
>>>> aborting
>>>> a save point? I ask particularly in light of:
>>>> On Sat, Jan 16, 2010 at 2:26 PM, Laurence Rowe <l...@lrowe.co.uk> wrote:
>>>>> 2010/1/16 Laurence Rowe <l...@lrowe.co.uk>:
>>>>>> I'm still not sure this will allow me to add savepoint release support
>>>>>> to zope.sqlalchemy, as SQLAlchemy has a concept of nested transactions
>>>>>> rather than savepoints.
>>>>>> http://groups.google.com/group/sqlalchemy/browse_thread/thread/7a4632587fd97724
>>>>> Michael Bayer noted on the sqlalchemy group that on RELEASE SAVEPOINT
>>>>> Postgresql destroys all subsequent savepoints. My branch now
>>>>> implements this behaviour.
>>> For zope.sqlalchemy I commit the sqlalchemy substransaction on
>>> savepoint.release(). This translates to a RELEASE SAVEPOINT on
>>> postgresql, best described by their docs here:
>>> """
>>> RELEASE SAVEPOINT destroys a savepoint previously defined in the
>>> current transaction.
>>> Destroying a savepoint makes it unavailable as a rollback point, but
>>> it has no other user visible behavior. It does not undo the effects of
>>> commands executed after the savepoint was established. (To do that,
>>> see ROLLBACK TO SAVEPOINT.) Destroying a savepoint when it is no
>>> longer needed allows the system to reclaim some resources earlier than
>>> transaction end.
>>> RELEASE SAVEPOINT also destroys all savepoints that were established
>>> after the named savepoint was established.
>>> """
>>> http://developer.postgresql.org/pgdocs/postgres/sql-release-savepoint.html
>>> Laurence
> --
> Jim Fulton
For more information about ZODB, see http://zodb.org/

ZODB-Dev mailing list  -  ZODB-Dev@zope.org

Reply via email to