0 None
Indicates that transactions are not supported.
1. Read Uncommitted
Transactions are supported, but no isolation.
- i.e.: one can do a rollback
- but one will potentially see changes from other (concurrent) txns
2 Read Committed
In this isolation level only statements that have been committed (at some point) can be seen by the transaction.
- Transactions in this level can (like all levels) see their own changes in read operations (both committed and uncommitted).
- Results may be inconsistent if results are being iterated through when the state of the store is changing.
- Each operation can be cached independently, so long as the cache of any two operations that can observe the same statement are validated together.
- This isolation level can be implemented with weak consistency using HTTP's Cache-Control max-age parameter as long as any cache item that is added or updated also causes any other cache item that could observe the same statement to be validated.
3 Repeatable Read
In addition to read committed, statements in this isolation level that are observed within a successful transaction will remain observable by the transaction until the end.
- Phantom reads are still possible in this isolation level.
- This isolation level is good for inferencers that can't handle disappearing statements, but don't require a full snapshot.
- New statements may be added in this isolation level, but they cannot be removed if they have been observed.
- This isolation differs from read committed only in the way it handles removed statements.
- A store could implement this by ensuring that no statements are removed when another transaction is open in repeatable read.
- If a statement was removed from the store from another transaction, a store can throw a ConcurrencyException (on next commit).
- Transactions in this isolation should be prepared for a ConcurrencyException when committed if an observed statement might not have been observed in later operations.
4 Snapshot
In addition to repeatable read, successful transactions in this isolation level will view a consistent snapshot. This isolation level will observe either the complete effects of other change-sets and their dependency or no effects of other change-sets.
- The underlying store will not appear to change by other transactions.
- Phantom reads are not possible in this isolation level.
- Multiple transactions may operate in the same snapshot and have their change-sets merge together into the store.
- The snapshot used may be a snapshot of the store before the transaction started, when the transaction started, or after the transaction started, so long as the transaction observes a consistent view of the store.
- This can be implement using a multiversion RDF store.
- This is the highest level the FederationSail could provide if its members supported serializable two-phase commits.
- This could be implement with multiple RDF stores that are periodically synchronized together.
- If for any reason the store cannot or does not provide a consistent snapshot to a snapshot transaction, it must throw a ConcurrencyException when the transaction is committed.
- Transactions in this isolation should be prepared for a ConcurrencyException when committed.
5 Serializable
In addition to snapshot, this isolation level requires that all other successful transactions must appear to occur either completely before or completely after a successful serializable transaction.
- This could be implemented with an exclusive lock on the RDF when a transaction is in this isolation.
- It could also be implemented with a multiversion RDF store that prevents conflicting change-sets from both being committed.
- An optimistic SAIL wrapper could provide concurrent serializable transactions, when the delegate store only supports linear transactions by rolling back transaction that would have read the newly committed changes.
- The store can throw a ConncurrencyException if it cannot completely order all operations of other transaction before or after a transaction.
- Transactions in this isolation should be prepared for a ConcurrencyException when committed or closed.
