[keycloak-dev] caching changes

[Bill Burke]

I'm still working on stuff, but here is a summary of things so far:
* ConcurrenyTest is passing
* Caching implementation is now a pessimistic locking style based on 
versions.  Locking never happens on reads, only writes.  There are two 
caches.  One cache holds the actual data, and is pretty much a vanilla 
invalidation cache.  The other cache olds versioning information and is 
a local-only cache and just is an id->version map.  Given an id, what is 
the current version of it.  Hopefully, the implementation makes sure 
that you never are able to add or obtain a stale version of an object 
from the cache.  Locking happens for updates.  At the end of a 
transaction, all registered invalidations are iterated on, and a version 
cache lock on that id is obtain.  The db is updated, and after that the 
locks are released.  A lock is also obtained whever something is added 
to the cache.  Again a lock is only obtained on the version cache, so 
any reads will never block.
* KeycloakTransactionManager now has an enlistPrepare method.
* There is a new RealmProvider.getClientByClientId() method. Clients now 
have a clientId "index" in the cache.
* There is a new RealmProvider.removeClient() method.  This was needed 
to support getClientByClientId()

Some other things that were done:
* Unnecessary @JoinTables were removed for certain @OneToMany relationships.
* getId() will no longer cause a DB query if you are invoking on a 
reference to a JPA adapter
* RealmModel.getClients() and getClientNameMap() is no longer used to 
implement getClientByClientId() :)
* CachedRealm now stores PrivateKey, PublicKey, and Certificate in a 
transient variable.  We were actually unmarshalling from the cached pem 
format every time these things were access, which is like few times per 
login.

Next steps:
* Create a client list cache for each realm.  Currently, if you 
add/remove a client, this invalidates the realm cache and its doing a 
big query for each client.
*  Do some profiling to see if there's other things we can do.

-- 
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com