compared with
Current by Nikola Petrov
on Apr 24, 2015 19:28.

This line was removed.
This word was removed. This word was added.
This line was added.

Changes (10)

View Page History
Another approach is to download the full version of Sesame and configure GraphDB-SE as a plug-in. This method uses the Sesame HTTP server hosted in Tomcat (or similar) and in this way you can use Sesame together with GraphDB as a server application, accessed via the standard Sesame APIs.

Sesame version 2.2 onwards includes the Sesame Workbench - a convenient Web Application for managing repositories, importing/exporting RDF data, executing queries, etc.

For more information please check the "doc" folder of the GraphDB-SE archive.
h5. How can I retrieve my repository configurations from the Sesame SYSTEM repository?

When using a LocalRepositoryManager, Sesame will store the configuration data for repositories in its own 'SYSTEM' repository. A tomcat instance will do the same and you will see 'SYSTEM' under the list of repositories that the instance is managing. To see what configuration data is stored in a GraphDB-SE repository, connect to the SYSTEM repository and execute the following query:


For GraphDB-Enterprise worker repositories the query is slightly different:

PREFIX sys: <>
PREFIX sail: <>

select ?id ?type ?param ?value
where {
?rep sys:repositoryID ?id .
?rep sys:repositoryImpl ?delegate .
?delegate sys:delegate ?impl .
?impl sys:repositoryType ?type .
optional {
?impl sail:sailImpl ?sail .
?sail ?param ?value .
# FILTER( ?id = "specific_repository_id" ) .
ORDER BY ?id ?param

This will return the repository ID and type, followed by name-value pairs of configuration data for SAIL repositories, including the SAIL type - "owlim:Sail" for GraphDB-SE and "swiftowlim:Sail" for GraphDB-Lite. GraphDB-Enterprise master nodes are not SAIL repositories and have the type "owlim:ReplicationCluster".

There is no easy generic way of changing the configuration - it is stored in the SYSTEM repository created and maintained by Sesame. However, GraphDB allows overriding of these parameters by specifying the parameter values as JVM options. For instance, by passing \-Dcache-memory=1g option to the JVM, GraphDB-SE will read it and use its value to override whatever was configured by the .ttl file. This is convenient for temporary set-ups that require easy and fast configuration change, e.g. for experimental purposes.

Changing the configuration in the SYSTEM repository is trickier, because the configurations are usually structured using blank node identifiers, which are always unique, so attempting to modify a statement with a blank node by using the same blank node identifier will fail. However, this can be achieved with SPARQL UPDATE using a DELETE-INSERT-WHERE command as follows (please note that this is valid for GraphDB-SE repositories):


For GraphDB-Enterprise worker repositories, the Sparql update is slightly different:

PREFIX sys: <>
PREFIX sail: <>
PREFIX onto: <>
DELETE { GRAPH ?g {?sail ?param ?old_value } }
INSERT { GRAPH ?g {?sail ?param ?new_value } }
GRAPH ?g { ?rep sys:repositoryID ?id . }
GRAPH ?g { ?rep sys:repositoryImpl ?delegate . }
GRAPH ?g { ?delegate sys:repositoryType ?type . }
GRAPH ?g { ?delegate sys:delegate ?impl . }
GRAPH ?g { ?impl sail:sailImpl ?sail . }
GRAPH ?g { ?sail ?param ?old_value . }
FILTER( ?id = "repo_id" ) .
FILTER( ?param = onto:enable-context-index ) .
BIND( "true" AS ?new_value ) .

Modify the last three lines of the update command to specify the repository ID, the parameter, and the new value. Then execute against the SYSTEM repository. In this example, the enable-context-index is changed, but there are other parameters that can not be changed once the repository is created, e.g. the rule-set (in the case of GraphDB-SE).

If you receive a stack trace containing the following:

bq. Invocation of init method failed; nested exception is Unable to create logging directory /usr/share/tomcat6/.aduna/openrdf-sesame/logs
then this indicates that Tomcat does not have write permission to its data directory (where it stores configuration, logs, and actual repository data). To fix this, log in as root to the server machine and do the following:
To use custom rule files, GraphDB must be running in a JVM that has access to the Java compiler. The easiest way to do this is to use the Java runtime from a Java Development Kit (JDK).

h5. I am getting SocketTimout when uploading large files

This might be caused because the import is taking longer than the configured timeout for your application server. In the case of tomcat you can change/add a connectionTimeout parameter in the&nbsp;Connector&nbsp;element in *conf/server.xml* like this:
{code} <Connector executor="tomcatThreadPool"
port="8080" protocol="HTTP/1.1"
redirectPort="8443" />{code}
or disable upload timeouts by setting the&nbsp;*disableUploadTimeout* to false. More information can be found in tomcat's documentation&nbsp;[here|]

h5. Slow tomcat startup time on Linux

If you are seeing the following in the logs
Creation of SecureRandom instance for session ID generation using [SHA1PRNG] took [5172] milliseconds.
then try adding {code}
to your *CATALINA_OPTS* in **
You can check [this|] for more information and implications for this parameter

h1. Backup/restore/import/export

This method will stream a snapshot of the database's explicit statements into the 'export.trig' file.

A backup can also be done programmatically using the Sesame API. See the [RepositoryConnection.exportStatements()|] [RepositoryConnection.exportStatements()|] method and the example in the next question.

If it is possible to shutdown the repository, then a backup can be effected by copying the GraphDB storage directory (and any sub-directories). See the [installation section|GraphDB-SE Installation] for information about where GraphDB storage folders are located. To restore a repository from a back up, make sure the repository is not running and then replace the entire contents of the storage directory (and any sub-directories) with the backup. Then restart the repository and check the log file to ensure a successful start up.
The basic procedure is to export the RDF data from the old version of GraphDB-SE and then reload it into a new repository instance that uses the new version of GraphDB-SE. Exporting is straightforward when using the Sesame workbench - simply click the 'Export' button, choose the format, and click 'download'. To import into a new repository, click 'add', select a format, specify the file and base URI, then click 'Upload'.

If not using the Sesame workbench, the export must be done programmatically using the {{RepositoryConnection.getStatements()}} API, because the Sesame console does not have an export function.
NOTE: It should be possible to export only the explicit statements, as the inferred statements will be recomputed at load time. Fortunately, the Sesame console application does have a 'load' function and this can be used to reload the exported statements.

The XML parser will generate an error similar to the following:

bq. Parser has reached the entity expansion limit "64,000" set by the Application.
when it generates more than a specified number of 'entities'. The default limit for the built-in Java XML parser is 64,000, however it can be configured by using a Java system property. To increase the limit, pass the following to the JVM in which GraphDB/Sesame is running. Note that the actual value can be increased as necessary. Don't forget that if running in Tomcat then this must be passed to the Tomcat instance using the CATALINA_OPTS environment variable.