apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Chris Darroch <chr...@pearsoncmg.com>
Subject Re: [PATCH]: Introduce APR DBD transaction mode
Date Mon, 01 May 2006 15:47:09 GMT
Bojan Smojver wrote:

> Here is the patch along the lines of setting the modes of the  
> transaction. It doesn't have "force commit", but if the list decides  
> that it's the right thing to do, I'll rework. I didn't test this -  
> it's just a prototype. A patch for folks using MySQL is included as  
> well.

   Looks pretty good to me.  I think you're right that we only
need commit and rollback as options for the end of a transaction,
but for possibly surprising reason (see below)....

Nick Kew wrote:

> There's rather more than that: after any failed operation within
> a transaction, apr_dbd assumes transaction failure and declines
> to attempt any further ops, without reference to the backend.

   I think perhaps we should remove this logic from all the drivers
entirely.  Here's why, and it connects back to my initial notion
of a "forceable commit" option, which I realize now was really
based on an instinct that I'd sometimes want to override the
built-in decision by apr_dbd to cancel my transaction.

   A simple example from (my) real life would be that I sometimes
want to insert a row and, if a constraint violation occurs, do
something else.  If I do that work outside an apr_dbd transaction,
no problem.  If I do it inside, though, apr_dbd will prevent
me from proceeding once I get the constraint violation.

   Applications using apr_dbd without transactions already have
to handle all the possible errors that they care about from
the databases they're using.  We don't, for example, have the
apr_dbd drivers attempt to map all possible DB errors to a
standard set of APR errors -- that would just be an impossible task,
I think.  So I'm inclined to say that when using transactions,
things should be no different; apr_dbd should get out of the
way and let the application decide which errors it can recover from.

   Here's another real-life example; this one is database-specific.
I sometimes register application-defined error codes with Oracle
and then set up triggers to throw those errors based on some PL/SQL
logic.  These are errors that are meaningful to my higher-level
application and in some cases signal it to do something else;
I don't really want apr_dbd deciding that one of these errors means
the whole transaction is bad.

   Thoughts, flames?


GPG Key ID: 366A375B
GPG Key Fingerprint: 485E 5041 17E1 E2BB C263  E4DE C8E3 FA36 366A 375B

View raw message