Mailing-List: contact dev-help@apr.apache.org; run by ezmlm
Precedence: bulk
Received-SPF: pass (asf.osuosl.org: domain of bojan@rexursive.com designates
 203.171.74.242 as permitted sender)
Message-ID: <20060502144538.gi44ih28j4sk4w0g@www.rexursive.com>
Date: Tue, 02 May 2006 14:45:38 +1000
From: Bojan Smojver <bojan@rexursive.com>
To: APR Development List <dev@apr.apache.org>
Subject: Transaction modes, explicit rollbacks etc.
MIME-Version: 1.0
Content-Type: text/plain;
	charset=ISO-8859-1;
	DelSp="Yes";
	format="flowed"
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
User-Agent: Internet Messaging Program (IMP) H3 (4.1.1)

So, we know by now that some databases will fail the whole transaction =20
if any kind of error occurs, while some others won't. We also know =20
that sometimes one option is the desired behaviour, while at other =20
times the other option is what the caller wants - regardless of the =20
underlying database. So, given that APR DBD is supposed to be database =20
neutral, here is another solution for the same problem.

#define APR_DBD_TRANSACTION_COMMIT        0x00 /**< commit the transaction *=
/
#define APR_DBD_TRANSACTION_ROLLBACK      0x01 /**< rollback the =20
transaction */
#define APR_DBD_TRANSACTION_IGNORE_ERRORS 0x02 /**< ignore error conditions =
*/

We then have our already known functions:

apr_dbd_transaction_mode_get()
apr_dbd_transaction_mode_set()

So, we can call (once only!):

apr_dbd_transaction_mode_set(driver, trans,
                              APR_DBD_TRANSACTION_COMMIT|
                              APR_DBD_TRANSACTION_IGNORE_ERRORS);

Then, inside the query/select functions we leave trans->errnum at zero =20
in case any error occurs, but return the status to the caller. If the =20
caller is intersted in the status, he/she can do something about it =20
(such as call mode set with ROLLBACK and then call end, to rollback). =20
Or, the caller can just continue with the next query/select. With =20
IGNORE_ERRORS set, at no point will the transaction be in a bad state =20
(i.e. this is how SQLite/Oracle/MySQL work). After all that, COMMIT is =20
executed and whatever is good gets committed (so this is effectively =20
COMMIT_ON_SUCCESS, but without the need to keep "recovering" the error =20
status).

In case the IGNORE_ERRORS flag isn't set, the logic reverts to the =20
current behaviour (i.e. the way PGSQL does things). Any error triggers =20
a transaction error and the whole transaction will be rolled back for =20
sure.

Here is the part we can now do with IGNORE_ERRORS that we could not do =20
before - we can make PGSQL behave like other databases if we so wish. =20
By setting IGNORE_ERRORS, we can insert SAVEPOINTS before every =20
query/select inside PGSQL driver automatically (i.e. the caller =20
doesn't have to do it). If an error occurs withing query/select, we =20
simply roll back to the previous savepoint, keep trans->errnum always =20
at zero and return the error code of the actual query. The caller can =20
then decide what should be done with the whole thing. This brings us =20
in line with transactional behaviour other databases.

In summary, we can pick the behaviour we want and users get =20
savepoints/error recovery for free with PGSQL if they so wish.

Let me know what you think...

--=20
Bojan