Contents   Index

Durability

When a transaction is finally committed (successfully), then the changes brought about it should be persistent. In other words the doings of the transaction can only be changed (or undone) by executing new commands or transactions that operate on the "results" of the committed transaction.

In mobile computing it may take a while before the changes made by a transaction reach the server and are (finally) committed there. In the mean time, it makes sense to let new transactions continue working on the in some sense un-committed data. If the first one at a later time is found out to fail then the "following" transactions must fail to, of course. However until that time the doings of a transaction may seem committed to new transactions. This leads to the following definition of pending transactions: A transaction is pending or tentative until it has been committed on the server, though it may appear to be committed from a clients, e.g., a disconnected ones, point of view.

In mobile computing we then have transactions executing and committing (or rolling back) in two stages; on a client and on the server. So an implementation would have to consider the stages of executing, committing, and rolling that are listed in Tables 4.1 and 4.2.

Table 4.1: Different stages for execution and commit of a transaction

$LET$	Local Execution-Time	execution-time in [34]
$LCT$	Local Commit-Time	tentative commit on client
$SET$	Server Execution-Time	re-execution on server
$SCT$	Server Commit-Time	commit-time in [34]

Table 4.2: Different stages for rollback of a transaction

$LER$	Local Execution Rollback	during local execution ($LET$)
$LCR$	Local Commit Rollback	at local commit time ($LCT$)
$SER$	Server Execution Rollback	during server (re-)execution ($SET$)
$SCR$	Server Commit Rollback	at server commit time ($SCT$)

  Contents   Index