JarCasting
JarCasting JarCasting

IndexedCache

A queryable object store with caching features

License

License
Categories

Categories

Dex General Purpose Libraries Utility
GroupId

GroupId

com.alkimiapps
ArtifactId

ArtifactId

indexed-cache
Last Version

Last Version

0.1
Release Date

Release Date
Type

Type

jar
Description

Description

IndexedCache
A queryable object store with caching features
Project URL

Project URL

https://github.com/alkimiapps/IndexedCache
Source Code Management

Source Code Management

https://github.com/alkimiapps/IndexedCache.git

Download indexed-cache

Filename Size
indexed-cache-0.1.pom
indexed-cache-0.1.jar 14 KB
indexed-cache-0.1-sources.jar 8 KB
indexed-cache-0.1-javadoc.jar 398 KB
Browse

How to add to project

<!-- https://jarcasting.com/artifacts/com.alkimiapps/indexed-cache/ -->
<dependency>
    <groupId>com.alkimiapps</groupId>
    <artifactId>indexed-cache</artifactId>
    <version>0.1</version>
</dependency>
// https://jarcasting.com/artifacts/com.alkimiapps/indexed-cache/
implementation 'com.alkimiapps:indexed-cache:0.1'
// https://jarcasting.com/artifacts/com.alkimiapps/indexed-cache/
implementation ("com.alkimiapps:indexed-cache:0.1")
'com.alkimiapps:indexed-cache:jar:0.1'
<dependency org="com.alkimiapps" name="indexed-cache" rev="0.1">
  <artifact name="indexed-cache" type="jar" />
</dependency>
@Grapes(
@Grab(group='com.alkimiapps', module='indexed-cache', version='0.1')
)
libraryDependencies += "com.alkimiapps" % "indexed-cache" % "0.1"
[com.alkimiapps/indexed-cache "0.1"]

Dependencies

runtime (4)

Group / Artifact Type Version
javax.cache : cache-api jar 1.1.0
com.googlecode.cqengine : cqengine jar 3.0.0
cglib : cglib jar 3.2.10
org.objenesis : objenesis jar 3.0.1

test (3)

Group / Artifact Type Version
org.ehcache : ehcache jar 3.6.3
junit : junit jar 4.12
org.mockito : mockito-core jar 2.23.4

Project Modules

There are no modules declared in this project.

WIP: IndexedCache

Build Status Test Coverage Maintainability Dependabot Status

A queryable object store with caching features.

Provides an in-memory object cache (optionally with persistence) that supports a range of queries for cached objects - i.e as opposed to simple key/value pair lookup.

All the hard work is done by CQEngine and whatever JCache implementation you choose to use with it. All that IndexedCache does is marry the two together so that all the features provided by CQEngine are available against a store that can be configured with limits for things like size and expiry where provided by the associated JCache.

In theory IndexedCache also implicitly supports any distributed caching that is provided by the associated JCache but this has not been tested and there is a caveat that is signficant for both distibuted and non-distributed caching in regards to objects being evicted from the JCache which is described below in the section labelled "Synchronisation Limitations".

Synchronisation Limitations

One of the roles of IndexedCache is to ensure that its associated IndexedCollection (from CQEngine) and JCache implementations are kept in sync. There are two limitiations in this regard:

1. JCache Eviction

Eviction is the removal of an item from a cache because of some policy. Cache eviction is commonly associated with cache size or the number of elements in the cache. When size or number of elements are limited and the limit is reached then the cache will evict elements in order to make room to store new elements.

The JCache specification makes no provision for observation of cache eviction events. (E.g. see https://github.com/jsr107/jsr107spec/issues/403)

JCache supports observation of creation, expiry, removal and update event. The removal event may or may not include eviction - that is up to the implementation. EhCache v3 for instance does not publish a remove event when an item is evicted from its JCache implemention.

Thus when the JCache associated with IndexedCache evicts elements, IndexedCache is unaware and cannot make a corresponding update in its associated IndexedCollection

One way to work around this limitation is to indepdently observe native cache eviction events where supported by the JCache implementation. When an eviction event is observed, invoke the IndexedCache.remove method to remove the element from the IndexedCache which will in turn remove the element from the associated IndexedCollection

2. IndexedCollection changes

As of CQEngine v3.0.0, IndexedCollection does not support observations of change events such as creation, removal or update of its contents. When any such event occurs on the IndexedCollection associated with IndexedCache but outside of the IndexCache APIs, then the associated JCache will become out-of-sync with the IndexedCollection.

Avoiding this limitation should be easy i.e. do not directly invoke any IndexedCollection APIs directly on the IndexedCollection with which IndexedCache is associated. Instead use the APIs of the IndexedCache which implements the IndexedCollection interface.

Building

TODO

Using

TODO

Contributing

  1. Fork it (https://github.com/yourname/yourproject/fork)
  2. Create your feature branch (git checkout -b feature/fooBar)
  3. Commit your changes (git commit -am 'Add some fooBar')
  4. Push to the branch (git push origin feature/fooBar)
  5. Create a new Pull Request

TODO

  • More tests
  • EhCache 2 and 3 indexed caches in separate repos

Versions

Version
0.1