Feargal Reilly wrote:
On Tue, 01 Jun 2004 12:44:56 +0200
Ilja Booij <[EMAIL PROTECTED]> wrote:
We'll also have to make sure that we call commit or rollback
when returning with an error code.
Ilja
I'm just underlining this WRT the daemons as a missing commit or
rollback could lead to really bizarre behaviour with later
invocations.
As a safeguard, there should be a global transaction flag which
is set by db_begin/commit/rollback(). This can essentially be
used as a lock with appropiate checkpoints.
Postgres will allow a BEGIN statement mid-transaction, although
it does give a warning. I'm not sure how other dbs act, but for
peace of mind this should be coded into the daemon instead of (or
complement to) relying on the backend.
Good point.
This can be solved by having a function like this:
int set_transaction_flag(int new_transaction_flag_value)
{
static int current_transaction_flag_value = 0;
if (new_transaction_flag_value == current_transaction_flag_value) {
screem_in_terror();
return -1;
} else {
current_transaction_flag_value = new_transaction_flag_value;
}
return 1;
}
or something similar. This function can be called by
db_begin_transaction(), db_commit_transaction() and
db_rollback_transaction().
We can even let it fail with a FATAL in the event that we're trying to
set the wrong flag, as it basically is a programming error, and we
should probably shutdown if it happens.
Ilja
