ikipedia.org/wiki/ACID">this Wikipedia article. At the end of the logical operation, it is either {@link #commit()}:ed, i.e. persisted to the database storage, or {@link #rollback()}:ed, i.e. discarded.
A transaction always involves just one execution thread. Several different threads may have their own transactions, and the transactions' ACID:ity properties guarantee that they will never see data in an intermediate state. This is accomplished by the thread locking implemented in the involved databases.
HeliDB has both read/write and read only transactions. It is up to the {@link org.helidb.Database} implementation used if they are treateddifferently. For instance, a {@code Database} could allow several concurrentread only transactions, but only one simultaneous transaction if that transaction is read/write.
A new transaction is started by any of the static {@link #startTransaction(boolean)} or {@link #getOrStartTransaction(boolean)}methods. If the thread already is involved in a transaction and wants to get that transaction's {@code Transaction} object, it can call any of the staticgetter methods.
Implementation note:
A database joins a {@code Transaction} via its{@link TransactionCollaborator}. It uses one collaborator object per transaction it is involved in. The collaborator keeps track of the state for the database associated with just that transaction.
@author Karl Gustafsson
@since 1.0
@see TransactionCollaborator
@see TransactionalDatabase