TDB Transactions

API for Transactions

TDB1 and TDB2

TDB1, the original native TDB database for Apache Jena, and TDB2 are related but different systems. Their transaction systems both provide Serializable transactions, the highest isolation level. with one active write transaction and multiple read transactions at the same time.

TDB2 does not have the transaction size limitations of TDB1.

TDB1

The transaction mechanism in TDB is based on write-ahead-logging. All changes made inside a write-transaction are written to journals, then propagated to the main database at a suitable moment. This design allows for read-transactions to proceed without locking or other overhead over the base database.

Transactional TDB supports one active write transaction, and multiple read transactions at the same time. Read-transactions started before a write-transaction commits see the database in a state without any changes visible. Any transaction starting after a write-transaction commits sees the database with the changes visible, whether fully propagates back to the database or not. There can be active read transactions seeing the state of the database before the updates, and read transactions seeing the state of the database after the updates running at the same time.

TDB provides Serializable transactions, the highest isolation level.

Limitations

  • Nested transactions are not supported.
  • Some active transaction state is held exclusively in-memory, limiting scalability.
  • Long-running transactions. Read-transactions cause a build-up of pending changes;

If a single read transaction runs for a long time when there are many updates, the system will consume a lot of temporary resources.

TDB2

The transaction mechanism in TDB2 is based on MVCC using immutable datastructrures, which are known as “persistent data structures” (although this name, for the functional programming community, is slightly confusing).

Limitations

(some of these limitations may be removed in later versions)