With Silhouette, you have the option of caching authenticators in your backing store. Due to this, we offer a cache implementation as well as a trait you can extend to implement your own cache backing store. The following are some suggestions on what you can do to implement it.

Implement caching

By default, Play is shipped with EHCache, a lightweight, in-memory cache. If this is not enough for your application architecture, there are at least two other caching options to use with Silhouette.



Please note, that you must pull in the Play cache dependency if you'll use the Play cache.

Use another Play cache plugin

Play has its own cache plugin architecture. So the easiest approach is to use another cache plugin for Play. You can then use the PlayCacheLayer implementation and plug a new cache into your application.

Implement your own cache layer

Silhouette provides a CacheLayer trait which can be used to create a custom cache implementation.

Clustered environment

If you use a clustered environment for your application then make sure that you use a distributed cache like Redis or Memcached. Otherwise cached artifacts must be synchronized between instances.

Development mode

When using the default Play cache in development mode, the cache will be cleaned after every app reload. This is because Play's cache (EHCache) is configured to store the data only in memory by default. This can be changed by overriding the shipped ehcache.xml from the jars to persist the cache on the disk.

To change the default behavior you must copy the ehcache.xml from the distribution jars to your configuration directory. Then add <diskStore path="java.io.tmpdir"/> and change diskPersistent to true. The following example shows a possible configuration. Adapt it to fit your needs.

<ehcache xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"

    <diskStore path="java.io.tmpdir"/>



You can also get around this issue by using a distributed cache like Redis or Memcached.

What’s Next