The major differences between GraphDB-SE and GraphDB-Lite are their performance and scalability. Both GraphDB editions deliver identical functionality for RDF storage, inference and query answering, and they both implement Sesame's SAIL APIs, as discussed in section 4. This guarantees that all essential functions of a semantic repository are supported by GraphDB in a standard, consistent, and interoperable manner.
GraphDB-Lite stores the repository contents in a binary file in the storage folder when it is shutdown. The format is such that it can be quickly read back in to memory when GraphDB-Lite is restarted, i.e. the synchronisation of the in-memory contents of the repository with a persistent binary storage file occurs only at initialisation and shutdown.
Transaction support is exposed via Sesame's RepositoryConnection interface. The three methods of this interface that give the client control over when updates are committed to the repository are shown below:
GraphDB supports the so called 'read committed' transaction isolation level, well known to relational database management systems. It guarantees that changes will not impact query evaluation, before the entire transaction, they are part of, is successfully committed. It does not guarantee that execution of a single transaction is performed against a single state of the data in the repository. Regarding concurrency:
One should note that GraphDB performs materialisation, making sure that all the statements which can be inferred from the current state of the repository are indexed and persisted. When the commit method completes, all reasoning related activities related to the changes in the data introduced by the corresponding transaction will have already been performed.
As already described, GraphDB-Lite applies the inference rules at load time in order to compute the full closure. Therefore, a repository will contain some statements that are explicitly asserted and other statements that exist through implication. In most cases clients will not be concerned with the difference, however there are some scenarios when it is useful to work with only explicit or only implicit statements. The following sections describe how these two groups of statements can be isolated during programmatic statement retrieval using the Sesame API and during (SPARQL) query evaluation.
The method retrieves statements by 'triple pattern', where any or all of the subject, predicate and object parameters can be null to indicate 'wild cards'.
To retrieve explicit and implicit statements, the includeInferred parameter must be set to true. To retrieve only explicit statements, the includeInferred parameter must be set to false.
GraphDB-Lite features thread-safe techniques for managing the internal storage of data structures, where several 'worker' threads do inferencing in parallel. The number of worker threads is controlled via the num.threads.run=n system property, see section 8.4. Each of the allocated threads operates on jobs of committed explicit statements. Each thread computes the increment to the inferred closure from applying the rule set to these new statements and the existing statements in the repository. The number of collected statements is controlled via the jobsize configuration parameter. When transaction is committed, the caller is blocked until all worker threads have finished their job units.
Skip to end of metadata Go to start of metadata