How does Polyhedra support transactions?

Polyhedra supports transactions, whereby a client can send down a group of changes to be performed together. Polyhedra enforces the 'ACID' properties:

The Polyhedra transactional model is very simple, as is appropriate for a system designed for real-time work. Basically, there are four main types of request from a client to a server:

To understand how these are handled by the server, it is best to envisage these requests being put onto a queue, and processed in turn - so that everything is serialised. (This is an over-simplification, as explained below).

CL in transactions

If CL is attached to the database, any CL triggered as the result of a transaction is performed within that transaction; the CL code has the ability to abort the transaction if it finds an application error, and any changes done by the CL code are rolled back if the transaction has to be aborted for any reason.

Limited parallelism

Although the transactional model is described as though everything is serialised, in fact the database server uses separate threads and table-level locks to allow a degree of parallel execution (for 'fairness', and to get better performance on multi-core or multiprocessor machines) while preserving the semantics of full serialisation. Thus, queries from separate clients can operate simultaneously, and each will put non-exclusive (read-only) locks on the tables they are reading; meanwhile a separate thread performing a batch of SQL DML will accumulate exclusive locks on on the tables it is altering. Normally, there is at most one update transaction running at a time, but under certain circumstances it is possible to allow many to run at once - see the server reference manual for details of how to enable this mode (and the restrictions that apply).

This topic was listed under the following topic areas:

  • transactional model