There are two reasons to use caching. First, to improve performance by
reducing the number of writes to the disk. Second, to share session data
in a clustered deployment. Janssen supports a few different options for
caching, as controlled by the
cacheProviderType. Also keep in mind that unless
sessionIdPersistInCache is set to
True, Auth Server will store sessions
in the database.
In-Memory If you only have one server, you can use RAM as the cache. Watch the memory usage of Auth Server--if it gets too high you may want to switch to another cache mechanism.
Database A "database cache" is an oxymoron. But in cases where you don't want another component or service, but you need the session replication for a cluster, it may be convenient to persist the "cache" data in the database.
Couchbase If you are already using Couchbase for persistence, then Janssen Auth Server can use "ephemeral buckets", which exist only in memory, for caching.
Redis The best choice if you need a cache service for LDAP, RDBMS, or Spanner. Great performance and low cache miss rate. Commercial Redis supports TLS, which is a good option if you need secure communication.
Memcached Still a good choice, especially if that's what you already run for other applications. We have observed a slightly higher cache miss rate under high load, which is fairly atypical for most login applications.
Cloud Cache Amazon ElastiCache or Google Memorycache offer both Redis and Memcached services. They work fine.