JOB Session

Sessions are connections to JOB instances fulfilling three main tasks:

  • Management of persistent maps,
  • management of persistent objects,
  • changes of persistent maps in the context of transactions,

Transactions

JOB transactions comply with the ACID principle. They are exclusively owned by sessions. Each session exactly owns one transaction. Transaction instances are transparent to JOB applications and are hidden by session instances. For this reason, JOB does not define any transaction interface. JOB transactions have properties controlling transaction semantics:

  • Isolation level,
  • optimistic transaction mode.

These properties are assigned during transaction activation calling one of the following overloaded methods on a session instance: 

    void begin(String isolationLevel, boolean optimistic)
void begin(String isolationLevel)
void begin(String optimistic)
void begin()

Method begin() (without arguments) assigns default properties to the activated transaction. Once a transaction is activated, its properties can not be changed. The following methods deactivate transactions: 

    void end()
void rollback()

Method end() commits changes to persistent maps applied since the transaction has been activated. Method rollback() rolls back these changes.

Isolation Levels

Transactions are activated for particular isolation levels. Isolation levels control the visibility of data of concurrent transactions. Several levels are defined for this purpose.

Serializable

Concurrent transactions are called serializable if any order of serialized executions does not have different effects on data. By definition, two concurrent transactions are serializable if they process different data or if they read data. Two concurrent transactions are not serializable if one of them change the same data which the other reads. Serializable is the strongest level of isolation for concurrent transactions.

Repeatable Read

This isolation level guarantees to read the same data for the same key multiple times within transaction boundaries. This holds even true, if data is read again, after concurrent changes on the same data by different transactions. Repeatable Read weakens Serializable isolation.

Commited Read

This isolation level guarantees to read commited data. Multiple reads for the same key are not guaranteed to select the same data. The data might have been changed and commited by concurrent transactions. Thus, Commited Read weakens Repeatable Read isolation.

Dirty Read

This isolation level does not guarantees to read commited data. Non-commited changes by concurrent transactions are visible. Thus, Dirty Read weakens Commited Read isolation.

Pessimistic / Optimistic Transaction Mode

Transactions are running either in pessimistic or optimistic mode. These modes differ in the point of time when isolation conflicts are checked. Pessimistic transactions check for conflicts at the time data is accessed or changed. In contrast, optimistic transactions check for conflicts at the time data is commited.

Nested Transactions

In contrast to transactions, nested transactions are dependent on parent transactions. Nested transactions are capable to read data changed by parent transactions. They may have nested child transactions. Successful commits of nested transactions may be rolled back by parent transactions.

Nested transactions are started by consecutive calls of method begin() . Calls of method end() or rollback() close parent or nested transactions. These methods are called on session instances.

Note : JOB does not support concurrent nested transactions having the same parent. Parent as well as nested transactions can only have a single child transaction.