Infinispan Based Storage Service

[Manuel Haim]

Hi Paul,

this is exactly what we have been trying to do with our StorageService,
being smart about the stored objects. As long as the Shibboleth IdP does
not get smarter about the StorageService ;)

Whether you use Memcached (via spymemcached library) or Infinispan
shouldn't depend, they both seem to provide a good shared-memory
solution with some handwork left to be done. My colleagues had some
experience with Memcached and there was much less configuration to be
done (still having Terracotta in mind), so I went that way. Infinispan,
though, also has its charm for being Java, but needs some more
configuration. You may also note that performance may vary between
different solutions (not tested, but see page 35 of [1] - maybe
Hazelcast could be considered as an alternative to Infinispan as well).

Internally, we also have the sessionId key mapped to the Session object,
and other keys mapped to the sessionId string. And if there are
transient or non-serializable fields we need, we unwrap them explicitly
and put them in another object, which will then be restored when the
Session object is retrieved again.

Furthermore, remember that the Shibboleth IdP has no locking mechanism
for the StorageService. Thus, when putting an object back, your put
method might need to synchronize objects instead of just overwriting
them, as the object within the map may already have been updated by
another IdP node (or even another thread within the same IdP instance).
(We do the synchronization by locking the sessionId and comparing the
timestamps of both objects, and if the stored object is newer, we
beanCopy its fields into the local object. However, in more complex
scenarios with custom IdP extensions like [2], I was reported that this
solution may lead to even more ugly race conditions which may break the
StorageService.)

Another problem which just comes into my mind is deleting objects. How
would one ensure that, if one IdP node removes an object from the map,
it is not being edited by another IdP and finally stored back?

I guess, all you can do is testing if a self-implemented StorageService
really suits all your needs or breaks in some special case.

-Manuel


[1] Scale over the limits: an overview of modern distributed caching
solutions
(page 35 shows a performace comparison chart)
http://www.snoopal.com/documents/GaSovOTchHCsOF5X7bG691/-Scale-over-the-limits-an-overview-of-modern-distributed-caching-solutions

[2] Multi-Tab login
http://shibboleth.1660669.n2.nabble.com/Multi-Tab-Login-td5822458.html