Execution of Update Transactions
The execution of an update transaction is divided into two phases: the execution phase and the commit phase. During the execution phase, the operations of an update transaction are executed and data conflicts with other update transactions are resolved using a conventional concurrency control protocol such as 2PL. The new values from the write operations of a transaction are written in a private workspace of the transaction instead into the database immediately. When all the operations of the update transaction have been completed, it enters the commit phase in which permanent updates of the database will be performed by copying the new values from its private workspace into the database. Data conflict with the broadcast transaction will be checked in the commit phase, which is performed in a critical section. So, we can see that the update transactions adopt 2PL for resolving data conflicts with other update transactions and use an optimistic approach to detect conflicts with the broadcast transaction. There are two important advantages in dividing the execution of the update transactions into two phases. Firstly, it can significantly reduce the blocking probability and delay of the broadcast transactions. If a broadcast transaction wants to read a data item, which is already locked by an update transaction during its commit phase, the broadcast transaction will be blocked until the update transaction is committed based on the principles of 2PL. At the same time, the update transaction, which is holding the lock, may be blocked due to data conflicts with other update transactions. Due to transitive blocking, the blocking time of the broadcast transactions can be very long. Dividing the execution of an update transaction into two phases can greatly reduce the blocking probability and blocking time of broadcast transactions since data conflicts between update and broadcast transactions will occur only when the update transaction is in the commit phase, which is much shorter. Secondly, the detection of data conflicts between the update and broadcast transactions will become much easier. At the commit phase, the system will know which data items have been accessed by the update transaction. By comparing the write set of the update transaction with the read set of the broadcast transaction, the system can easily determine whether there is any data conflict between them.

Conflict Resolution between Update and Broadcast Transactions
Data conflict between an update transaction and a broadcast transaction is detected when the update transaction enters its commit phase. Re-broadcast is used to resolve the conflict by reversing the serialization order from BT ® U to U ® BT. The details of the algorithms at both the server and mobile clients are shown in the following sections.

Algorithm at the Server:

It is performed when an update transaction enters the commit phase.
On(transaction commit)
If O_BT Ç O_U = { }
then
BT and U have no dependency
else
for each data item d_i Î { O_BT Ç O_U }
re-broadcast data item di
endif

where O_BT = set of data items of broadcast transaction BT
O_U = set of data items of update transaction U

By re-broadcasting the conflicting data item, the serialization order between the broadcast transaction and the update transaction is reversed. The set of data items in the broadcast transaction consists of those data items, which are broadcast in the period from (current time ??life-span of a mobile transaction) to current time. Thus, the set of data items in the broadcast transaction is not fixed. After the broadcast of a data item, the data item will be included and the last data item in the broadcast transaction will be removed.

Algorithm at the Mobile Client
The data items requested by a MT are represented by a sequence of read operations. Processing of a MT starts from the first read operation in the sequence. Each data item received from a BT is matched with the requesting data item of the executing operation. If there is a match, the MT will read the data item and the operation will be processed. The process is repeated for the next read operation until there is no more operation in the sequence. In case a data item, which is already read, is re-broadcast while the MT is waiting for other data items, the MT will be restarted from the operation which requests that data item. It will use the re-broadcast value for the execution of the operation. There are two reasons for the restart. Firstly, it is to ensure the serializability order U ® MT. The second reason is to provide the most updated data values to the mobile transactions. The algorithm at the mobile client is shown below where it is assumed that the MT reads all its data items from BT and there is no cache at the client.

d_c = the data item required by the first operation in L_MT loop until L_MT exhausted
read data item d_i from BT (d_i is the currently broadcasting item)
if d_i = d_c
then
MT processes d_i and updates L_MT
else
if di Î SMT
MT repeats the processing on d_i , updates L_MT
Restarts its execution from the operation, which requires d_i
endif
endif
d_c = the data item requested by the next operation in LMT
end loop
where L_MT = sequence of read operations in MT
S_MT = set of data items have been accessed by MT