Beefy Boxes and Bandwidth Generously Provided by pair Networks vroom
Think about Loose Coupling
 
PerlMonks  

Re: Nested (sql) transactions

by tobyink (Abbot)
on Feb 04, 2012 at 00:38 UTC ( #951737=note: print w/ replies, xml ) Need Help??


in reply to Nested (sql) transactions

No, most databases don't support nested transactions, but many provide savepoints which allow roughly equivalent functionality. PostgreSQL and MySQL do; even recent releases of SQLite. Indeed, so does Microsoft SQL Server.

So if you want to write decent cross-database code, use savepoints instead of nesting transactions. Of course, as is often the case in SQL land, syntax for establishing a savepoint, rolling back to a savepoint, or releasing (kinda like committing) a savepoint vary from database to database. But not too badly.

Your code, as I understand it, when it wants a nested transaction, opens a new database connection, runs the nested transaction there, and holds the transaction open until it's sure the outer transaction is ready to commit. It's a reasonable solution in the case where you're on a database that does transactions but not savepoints.

However, I think it probably has some flaws. You'd typically want code running in an inner transaction to be able to "see" database changes already made in the outer transaction. But if your database is doing ACID properly, then an independent transaction on a second database connection will not be able to see the changes made in the initial transaction until that initial transaction has been committed.

Nested transactions do indeed have some advantages over savepoints. Savepoints need to be given names. That means that Perl code that is executing an SQL transaction, and calling other Perl modules to execute inner transactions, needs some co-ordination between modules to ensure that savepoint names are unique. Nested transactions are anonymous so don't have this problem.


Comment on Re: Nested (sql) transactions
Re^2: Nested (sql) transactions
by clueless newbie (Friar) on Feb 04, 2012 at 01:12 UTC

    tobyink:Your code, as I understand it, when it wants a nested transaction, opens a new database connection, runs the nested transaction there, and holds the transaction open until it's sure the outer transaction is ready to commit. It's a reasonable solution in the case where you're on a database that does transactions but not savepoints.

    However, I think it probably has some flaws. You'd typically want code running in an inner transaction to be able to "see" database changes already made in the outer transaction. But if your database is doing ACID properly, then an independent transaction on a second database connection will not be able to see the changes made in the initial transaction until that initial transaction has been committed.

    clueless:Thank you for those thoughts. It doesn't require opening a new database connection. No doubt my example was somewhat misleading.

    It leaves a lot to be desired as far as ACID is concerned.

Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://951737]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others chilling in the Monastery: (13)
As of 2014-04-17 14:43 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    April first is:







    Results (450 votes), past polls