All operations on the database participate in a transaction. By default, operations are committed as soon as possible, which in practice means immediately after each INSERT, UPDATE or DELETE. A common term for this is that statements are automatically committed (autocommit).
If several operations are to be grouped together into one single transaction, the transaction boundaries must be defined by calls to MimerBeginTransaction and MimerEndTransaction.
Transactions may abort. A transaction abort is a rollback forced by the system. A transaction abort occurs when a conflict with another session has been detected, for example when two transactions have been reading and updating the same data. The database system must decide to abort one of them and to save the other one to storage. The session seeing the aborted transaction must take some action depending on this, perhaps trying to update the database once again.
Issuing large transactions puts a special burden on the database server since read- and write-sets may grow large, thus consuming memory. The read- and write-sets are logs maintaining a record of what active transactions have done. Large read- and write-sets also has the implication that they put a larger overall burden on the database server since it may take time to manage them, particularly if they grow so large that they are written to flash or magnetic memories.