Apache Marmotta Site

Last Published: 2018-06-18

|

Version: 3.3.0

LDCache Backends

LDCache implements a modular architecture which allows using different kinds of backends for storing cache entries. Some of these backends are purely in-memory (i.e. don’t survive a restart and might even expire when memory runs out), others are file-based or even database-backed. In principle, an LDCache backend needs to be able to store the following two kinds of data:

cached triples: the triples retrieved from a remote Linked Data resource; triples can be stored either per-resource or in a common triple store; the way the backend solves it is up to the developer; on the interface level, developers always have to access the cached triples on a per-resource level (using the getCacheConnection(resource) method).

caching metadata: information about the caching process itself, most importantly expiry information and the date when the resource has last been retrieved

The following sections describe the LDCache backends that are currently available or will be available in the near future.

KiWi Backend

The KiWi backend for LDCache relies on an underlying KiWi triple store to store caching information. It will use the KiWi store’s JDBC connection to add additional tables and information to the database. The two kinds of caching data are stored as follows:

cached triples are stored together with all other triples in the KiWi triple store, but in a separate context (named graph) to be able to distinguish them from local triples; the advantage of this approach is that it allows storing all data in one place and makes the implementation of connection wrappers trivial and efficient

caching metadata is stored in an additional table in the database; the table is created when the backend is initialized; each time a resource is refreshed, its entry in the table is updated

The KiWi backend is the backend you should choose when you are using a KiWi triple store, except if you want to completely keep apart your local and your cached data. You can include the KiWi backend in your project using the following Maven artifact:

Note that the underlying KiWi repository must be initialized before using it in the LDCachingKiWiBackend, because otherwise the necessary database tables might not be present. The argument CACHE_CONTEXT is the URI of the resource to use as context (named graph) for storing and accessing cached triples.

EHCache Backend (under development)

The EHCache backend for LDCache relies on an EHCache caching infrastructure for storing caching information. When using the Open Source version of EHCache, this usually means in-memory caching only. However, for enterprise systems it is also possible to build a high-performance caching cluster that can be used by the LDCache backend (please refer to the EHCache documentation on how to set this up).

In the EHCache backend, both the caching metadata and the cached triples for a resource are stored in the same cache entry. To allow EHCache to serialize cache entries for distribution over the cluster or for swapping to disk, the triples are represented in a serializable in-memory representation.

Note: the EHCache backend is currently still under development. We therefore don’t publish Maven artifacts for it yet.

MapDB Backend (under development)

The MapDB backend uses the embedded NoSQL database MapDB (formerly known as JDBM) for storing cache information in a persistent disk-based hash map.

In the MapDB backend, both the caching metadata and the cached triples for a resource are stored in the same cache entry. To allow MapDB to serialize cache entries when persisting the hash map to disk, the triples are represented in a serializable in-memory representation.

Note: the MapDB backend is currently still under development. We therefore don’t publish Maven artifacts for it yet.