clustering with HazelcastStorageService

[Paul B. Henson]

> From: Cantor, Scott
> Sent: Thursday, April 28, 2016 2:35 PM
> 
> The configuration is to a specific storage service bean, it isn't based on any
> inherent limitations on the number of beans or their type. You could tell it to
> use one bean for different uses, or separate beans, and the beans could be
> of one type or separate types.

Ah, when I define the bean in the xml that is actually instantiating an instance of the class? Sorry again, spring/xml is not really my forte. I've got a pretty good grasp of the underlying theory and java itself but enterprise JavaBeans not so much.

> But you can't avoid a two part key. The system won't perform adequately if
> the operations based on it aren't efficient. Glomming the two halves
> together just isn't workable when you can't do the lookups efficiently.

I wasn't saying not to have a two-part key. Currently the context is just "<randomid>. I meant making it something like "session-<randomid>" which would allow the backend storage engine to know what it was dealing with and be able to put all of the session context data into a single session map rather than creating separate maps for every individual session.
 
> My general feeling is that it's not practical to document them. That one alone
> is an implementation class, so it's not stable. This simply isn't part of the
> allowable contract for an implementation of the storage API.
> 
> I think what you want to do here is actually create separate instances of the
> storage service bean and use them separately for different use cases. Seems
> to me that's the right level of separation for this if you need to configure
> these sorts of settings differently.

Possibly. But in general it seems for efficiency purposes any given storage engine might want to be able to be aware that any given item it is storing belongs to a set of "X" as opposed to a set of "Y"? Having a static context name for any given set (whether it is documented or not) allows the storage engine to do so, but having completely random context names for things that are of the same set does not.

Earlier you said "The context/key split is just a two part key to allow for co-habitation within one storage instance by different storage clients". I would consider the replay cache a storage client, the session cache a storage client and the CAS ticket cache a storage client. It seems that by having each individual session have its own distinct random context, you are treating each individual session as a separate storage client? If I were someone writing a storage backend, I would only expect to have maybe half a dozen or so storage clients, not thousands or more. Specifically in the case of the hazelcast storage backend, ending up having thousands or tens of thousands of storage clients I think is causing considerable inefficiency. I'm not quite sure how to address that yet, but I think one question needs to be in terms of the API, what exactly is a "storage client" then? And how many should a storage backend expect to see?

I took a quick look through the CAS code, and I'm not completely sure, but I think it is using the name of the service as the context when it is creating a session. So it is not completely random, but it would still be creating multiple maps with the hazelcast backend depending on how many different CAS services you had configured. So it would either need to have a context prefix added as well so the backend could recognize and collate all of those contacts into the same backend map or the possibility of instantiating multiple instances of the backend for each use case as you suggested would need to be investigated. I'm still just trying to understand everything :).

Thanks…

--
Paul B. Henson  |  (909) 979-6361  |  http://www.cpp.edu/~henson/
Operating Systems and Network Analyst  |  henson at cpp.edu
California State Polytechnic University  |  Pomona CA 91768