Re: undefined behaviour for sub-transactions?
- From: tyler@xxxxxx (Tyler MacDonald)
- Date: Mon, 14 Nov 2005 23:01:11 -0800
Paul DuBois <paul@xxxxxxxxx> wrote:
> MySQL doesn't have sub-transactions (nested transactions). You can set
> savepoints within a transaction and roll back to a given savepoint and then
> continue the transaction from there.
Hopefully it will some day. :) I'm guessing other DBI drivers have
this behaviour too... when DBI talks to a driver, does it know if it
supports sub-transactions? For that matter, does it know if there is a
transaction already in progress?
I'm trying to support multiple database drivers at once. I have
methods that do small tasks (such as updating a table), and methods that
glue these small tasks together into big tasks (such as updating a table and
all of it's foreign keys). Whether it is a small task or a large task that
is being done, I would like the operation to be completely atomic.
I have each small task do it's own "begin_work/commit", and then
each large task wraps the whole thing in it's own "begin_work/commit". With
an engine that supports nested transactions, this works perfectly. With
MySQL, all of the SQL is still executed and comitted, but I get a warning on
the last commit, even it PrintWarn is set to 0.
I'd rather not have to investigate / guess what every single DBD
driver does and add change the behviour based on $dbh->{Driver}->{Name}.
Is there a way to ask DBI if it is already in a transaction? If it
knows this and I can get that information out of it, I could make this
package a lot more useable.
Thanks,
Tyler
.
- References:
- undefined behaviour for sub-transactions?
- From: Tyler MacDonald
- undefined behaviour for sub-transactions?
- Prev by Date: Re: undefined behaviour for sub-transactions?
- Next by Date: Re: undefined behaviour for sub-transactions?
- Previous by thread: Re: undefined behaviour for sub-transactions?
- Next by thread: Re: undefined behaviour for sub-transactions?
- Index(es):
Relevant Pages
|