Transaction Types
The class ostc (named for the ObjectStore thin client) defines an enumeration that specifies transaction types:
enum transaction_type {
read, mvccRead, shared_update, isolated_update, none, any
};
Each instance of ostc_ServerOperation has a transaction type, which specifies the type of transaction in which it must be executed. You specify the transaction type when you create the instance.
Each Server also has a transaction type, which specifies the type of transaction the Server uses to execute operations. You specify a Server's transaction type when you configure the Server. You can also modify a Server's transaction type with ostc_ServerSession::setTxnType().
With all transaction types except isolated_update, the Server batches requests from different users into the same transaction, reducing commit overhead and increasing throughput.
read transactions can be used for operations that perform no updates to persistent data.
mvccRead transactions can be used for operations that perform no updates to persistent data and do not need a completely up-to-date version of the data - see Using the ObjectStore C++ Interface.
isolated_update transactions are for operations that perform updates to persistent data. Each transaction handles just one operation execution, whose results are committed once the operation completes.
shared_update transactions should be used only with extreme care. They are for update operations that can safely be batched into the same transaction with operations executing on other Server threads. For this to be safe, the operations must not potentially interfere with each other when accessing persistent data. Unsafe batching can produce incorrect results or database corruption.
any transactions should be used for operations that you want executed on the first available Server, regardless of transaction type. This cannot be used to specify the transaction type of a Server.
none is for operations that either access no persistent data.
Determining Whether Update Operations Can Interfere with Each Other
Operations potentially interfere with each other if some way of interleaving their primitive database reads and writes produces incorrect results.
Consider, for example, an operation to purchase a ticket for a specified seat at a particular performance. Suppose the operation performs one database read, to see if the seat is available, and one database write, to mark the seat as sold (if it was available). Now consider two executions of this operation running on different threads, in the same transaction. Their database reads and writes might be performed in the following order:
In this case, both executions will find the seat to be available, and two people will end up with tickets for the same seat. This is an incorrect result, so the operations can interfere with one another and cannot be batched safely.
Note that what counts as an incorrect result is application dependent. Note also that, even if some possible ways of ordering the primitive reads and writes produce correct results, as long as there is at least one ordering that produces an incorrect result, the operations cannot be batched safely.
It is often very difficult to determine if update operations can be batched safely. When in doubt, use isolated_update for update operations.
With read and mvccRead transactions, the operations perform only database reads, which can always be safely batched.
Batch Transaction Commits
The results of a shared_update operation are not committed to the client until the completion of all the operation executions in the same batch. From the client's point of view, this means that ostc_Session::doOperation() does not return until all the batch's operations complete. This also means that one thread performing a relatively lengthy operation can delay other threads. However, in many cases overall throughput is increased.
Results of read and mvccRead operations are returned to the client without waiting for all operations in the batch to commit, since an abort of one (read-only) operation does not affect the results of other operations in the batch.
shared_update Aborts
If one operation execution in a shared_update transaction aborts, all executions in the batch must be aborted.This means that using shared_update can increase the likelihood of your operation's being aborted.
[previous] [next]