The entity pool is a key component of the GraphDB storage layer. It converts the entities (URIs, Blank nodes and Literals) to internal IDs (32- or 40-bit integers). From version 6.2 this component supports transactional behavior, which improves space usage and cluster behavior.

Implementations

The transactional property of the entity pool fixes many issues related to creating IDs. However, entities still need to be pre-processed and all other commit operations should be performed (storing, inference, plugin handling, consistency checking, statement retraction on remove 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 classic one.

There are two implementations - a fully transactional and classic.

classic

• the default implementation
• recommended for large transactions and bulk loads
• avoids the overhead of temporarily storing of the entities and the remapping from temporary to permanent IDs (which is performed in the transactional implementation)
• when adding statements, the entities are directly added and cannot be rolled back

transactional-simple

• all new entities are kept in memory - not recommended for large transactions (> 100M statements) to prevent OutOfMemoryErrors
• good for large number of small transactions
• mandatory in cluster environment - ensures entity IDs consistency between worker nodes
• mandatory when used with Solr and Elascticsearch connectors

transactional

• the recommended for the current version of GraphDB transactional implementation. Currently it is transactional-simple. May change in future versions.

Configuration

The entity pool implementation can be selected by the entity-pool-implementation config parameter or the -D command line parameter with the same name.