GraphDB Entity Pool

Skip to end of metadata
Go to start of metadata
You are viewing an old version of this page. View the current version. Compare with Current  |   View Page History

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.

Parameter Value Description
entity-pool-implementation transactional-simple all entities are kept in memory
  classic (default) for bulk loads
Labels:
None
Enter labels to add to this page:
Please wait 
Looking for a label? Just start typing.