Bojan:
> By far the most important piece of software that uses APR 1.2.x is
> Apache 2.2 and associated modules. An upgrade of APR to 2.x there would
> most likely require an MMN bump. I'm not sure if Apache development
> policies permit this any more mid minor version. However, using APR
> 1.3.x, given it is binary compatible with 1.2.x, would probably be an
> option. So, the upgrade here is all about timing, AFAIK.
Good point. Well, here's a thought I'll just throw out there,
that might make things a little more like the way the Perl DBI
AutoCommit thingy works, and which might satisfy both binary
compability and Nick's preference for automatic commit/rollback
as the default in apr_dbd_transaction_end().
Instead of adding an apr_dbd_transaction_rollback() function,
what about adding the following:
#define APR_DBD_TRANS_COMMIT_ON_SUCCESS 0
#define APR_DBD_TRANS_COMMIT 1
#define APR_DBD_TRANS_ROLLBACK 2
#define APR_DBD_TRANS_DEFAULT APR_DBD_TRANS_COMMIT_ON_SUCCESS
APU_DECLARE(int) apr_dbd_transaction_mode_get(apr_dbd_transaction_t *trans);
APU_DECLARE(int) apr_dbd_transaction_mode_set(apr_dbd_transaction_t *trans,
int mode);
Then instead of the following sort of logic using
apr_dbd_transaction_rollback():
if (application_error) {
apr_dbd_transaction_rollback(...);
} else if (apr_dbd_transaction_end(...)) {
## handle unexpected error
}
you'd use instead something like this:
## this statement could be in a nested sub-function
if (application_error)
apr_dbd_transaction_mode_set(trans, APR_DBD_TRANS_ROLLBACK);
if (apr_dbd_transaction_end(...)) {
## handle unexpected error
}
Among other things, I'm thinking that this has some advantages
because it means that if an application encounters an error
deep in a nested set of functions, it can simply set the "mode"
flag on the transaction it's been passed and return up through
the stack. The high-level caller that created the transaction
can then simply end it, and if it wants to beforehand, check
the mode state.
Otherwise, a nested function that wants to force a rollback
has to either do so, and then signal to all the callers that
the transaction is dead (and they then have to handle that
condition), or it has to set some internal application flag
that must be checked before trying to end (i.e., commit) or
rollback the transaction. With the mode flag in APR, I think
some of this application-side logic might be eliminated. Thoughts?
Chris.
--
GPG Key ID: 366A375B
GPG Key Fingerprint: 485E 5041 17E1 E2BB C263 E4DE C8E3 FA36 366A 375B
