Using isc_prepare_transaction()
Go Up to Ending Transactions
When a transaction is committed against multiple databases using isc_commit_transaction()
, InterBase automatically performs a two-phase commit. During the first phase of the commit, the InterBase engine polls all database participants to make sure they are still available, writes a message describing the transaction to the RDB$TRANSACTION_DESCRIPTION
field of the RDB$TRANSACTION
system table, then puts the transaction into a limbo state. It is during the second phase that transaction changes are actually committed to the database.
Some applications may need to coordinate the two-phase commit with other processes. These applications can call isc_prepare_transaction()
to execute the first phase of the two-phase commit, then perform their own, additional tasks before completing the commit with a call to isc_commit_transaction()
.
The syntax for isc_prepare_transaction()
is:
ISC_STATUS isc_prepare_transaction(ISC_STATUS *status_vector,
isc_tr_handle *trans_handle);
For example, the following code fragment illustrates how an application might call isc_prepare_transaction()
, then its own routines, before completing a commit with isc_commit_transaction()
:
ISC_STATUS status_vector[20];
isc_db_handle db1;
isc_tr_handle trans;
. . .
/* Initialize handles. */
db1 = 0L;
trans = 0L;
. . .
/* Code assumes a database is attached here, and a transaction started. */
. . .
/* Perform first phase of two-phase commit. */
isc_prepare_transaction(status_vector, &trans);
/* Application does its own processing here. */
my_app_function();
/* Now complete the two-phase commit. */
isc_commit_transaction(status_vector, &trans);
It is generally a dangerous practice to delay the second phase of the commit after completing the first, because delays increase the chance that network or server problems can occur between phases.