in reply to Re: commtting db transactions
in thread commtting db transactions

thanks for the reply...
You can do it by subclassing DBI - possible, but not easy.

i actually started down this track, until i read the source of the DBI module and realised how many objects/packages were involved/would have to be overriden...

It is normally a Good Thing (tm) to have short transactions. Nested transactions are often a sign of design failures.

i agree that transactions (and thus table/column locks) should be kept short, however, in this case, all 'mini-transactions' must either all fail, or all succeed. hence, it seems the only answer is to perform a single, rather large transaction commit/rollback right at the end.

d_i_r_t_y

Replies are listed 'Best First'.
Re^3: commtting db transactions
by ryanus (Sexton) on Aug 07, 2005 at 22:30 UTC
    I am also looking into adding transaction support to a large Perl web application. I currently think the best way to add transaction support is by passing the responsibility to the caller (client) code. The basic problem is to define how large a "unit of work" is in your application. Each unit of work should have one transaction. I don't think that the API should dictate to the caller how large a unit of work is.