ONTOTEXT ANSWER:
GraphDB is an ACID database. The “I” in this acronym stands for Isolated. This means that each transaction is independent of all other transactions that may be happening at the same time. In other words, writes happen in the order in which they are issued and they can’t access information from the other writes going on in the same time.
However, GraphDB is multithreaded, which means some transactions may complete while others are still pending. Just like any other database, there’s a bit more to this than a simple queue.
Standard isolation levels
The problems that isolation aims to address are:
- a dirty read is reading data from another transaction that is not yet committed
- a non-repeatable read would be occurring when you try to read the same data twice within the same transaction, but a commit has already changed it, so you fetch two different values
- a phantom read would be reading new data that was committed ever since the transaction was started
GraphDB defaults to a Read committed serialization level. This means that it avoids dirty reads, but it carries a risk of non-repeatable and phantom reads. The standard isolation levels map to the following RDF4J isolation levels:
- NONE – read uncommitted, and no transaction rollback. Only suitable for bulk uploads.
- READ_UNCOMMITTED
- READ_COMMITTED
- SNAPSHOT – similar to read committed, but the transactions happen against a particular database snapshot.
- SERIALIZABLE
Non-repeatable reads and phantom reads are usually not problematic if you are not fetching the same data twice. It may be beneficial to be able to retrieve data that was freshly committed to the database. A dirty read is almost never useful.
GraphDB gives you the capability to control the isolation levels of your transactions when you are accessing it through the Java API. This is done using the IsolationLevels enumerator.
try (RepositoryConnection conn = rep.getConnection()) {
conn.begin(IsolationLevels.SERIALIZABLE);
....
conn.commit();
}
The default GraphDB repository supports READ_COMMITTED and all more permissive isolation levels. Stricter isolation levels can be supported thanks to the stackable SAIL interface that allows you to nest repository capabilities.


