The entity pool is a key component of the GraphDB storage layer. From version 6.2 it supports a transactional behavior, which improves space usage and cluster behavior.

Configuration

The transactionability of the entity pool fixes many issues related to creating IDs. However, you still need to pre-process the entities and perform all other commit operations, including adding the entities to the permanent store. All these operations are time-consuming, so the new transactional entity pool cannot be faster than the previous non-transactional one.

Therefore, we offer two options: a fully transactional implementation, as described above, and a 'classic' entity pool implementation, which avoids the overhead. The default is the 'classic' entity pool, which performs like the entity pool from the earlier GraphDB versions. It still uses connections and the same entity pool interface but when adding statements, the entities are directly added and cannot be rolled back.

The entity pool implementation can be selected by the entity-pool-implementation config parameter or the -D command line parameter with the same name. There are two possible values:

• transactional-simple;
• classic.

When in the transactional-simple mode, all entities are kept in memory. It is good to keep this in mind when dealing with large transactions as the memory dedicated for the transaction will be released only after the entities have been committed to the disk. Transactions up to 100 million statements should not present a problem but if they are much larger, it will occupy significant memory resources. Therefore, such big loads should be used with the 'classic' option in order to prevent OutOfMemoryErrors.

On the other hand, a large number of small transactions will have the same performance as before because the overall overhead per transaction is much larger than the overhead resulting from the transactional entity pool. So, the transactional-simple option is preferable over the classic one, especially in a cluster environment.