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

• Atomic.
  The changes of a transaction (together with any knock-on changes performed by trigger code attached to the database) are either all applied, or - if there is any reason for any of them to fail - are all cancelled, with the database rolled back to its pre-transactional state.
  
  
• Consistent.
  Any breach of the database integrity rules* causes the transaction to fail, so each successful transaction takes the database from one correct state to another.
  (*Polyhedra enforces entity integrity - where rows have to have the right number of columns, values have to be the correct type for the column, 'not null' attributes have to have a value and uniqueness constraints are enforced - primary key integrity - where each table has to have a designated column or set of columns, with each record uniquely identified by the value(s) in its primary key - and referential integrity: if a column or set of columns in a table are defined as a foreign key reference to another table (or even to the same table), then for each record the values in these columns are either all null or they match the primary key of a record in the designated table. In addition, Polyhedra allows 'triggers' written in CL to be attached to tables, and these can impose further constraints.)
  
  
• Isolated.
  The intermediate state of a transaction is invisible to other transactions.
  
  
• Durable.**
  Once a transaction is reported as successful, the initiator is entitled to assume the changes have been safely records, and so will be preserved even over a system failure.
  (**Polyhedra FlashLite enforces durability by default; Polyhedra IMDB leaves it up to the client to decide whether it is told of the successful transaction immediately upon completion, or only when it is known it has been successfully journalled to disk and - where applicable - applied to the standby server.)

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:

• an SQL query (which can be 'static' or 'active', as described below);
• some 'SQL DDL' to change the structure of the database - for example, the addition of a number of tables, or the addition of some columns to some existing tables;
• a group of SQL DML statements (insert, update, delete, etc), optionally followed by an SQL query; or,
• a set of updates to the result set of one or more active queries.

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).

• For a query, the database server just calculates the result set and sends it to the client. For normal (static) queries, that is all that is needed; for active queries, though, the server remembers enough about the query so that it can inform the client when relevant changes occur. (This is described in more detail in a separate FAQ.)
• For DDL or DML, the neccessary changes to the database are made and the client is told whether it was successful; in the case of DML which an appended query, if the tranasction was successful then the query is immediately evaluated (before any other transaction has a chance to update the database).
• For updates through active queries, where meaningful and possible the database server tries to alter the database contents to match the requested changes. However, a limited form of 'optimistic concurrency' is enforced, so that if the database has been altered recently a way that 'clashes' with any of the new changes, the new transaction will be abandoned. This is described further in the article on active queries.