I think we are starting to agree. I see the session manager as a
high level component that *can* be implemented on top of a cluster or
just be a local hash map. The idea was to create an abstraction such
that, the people writing clustering code can easily plugin into
geronimo services that have session data (which is about the only
pice of cluster data that we have right now).
As for low level Clustering apis, I don't have much of a preference
unless I have to write to them, and the stuff I'm working on can be
completely satisfied by the session api.
-dain
On Jul 14, 2006, at 6:41 AM, Filip Hanik - Dev Lists wrote:
Cool, thanks for posting this.
While I do believe everything in this API is very useful, I see it
as an extension to the one I created.
My API is only about the cluster, and its meta data, while the API
below is very session oriented.
In a cluster without state replication, most of the methods below
would return null or throw UnsupportedOperationException, hence it
would make it harder to implement, and less useful.
The API below is essentially meta data about session state. I
personally consider this an extension to the Cluster API, or a
higher level component, and bada bim, we are back at SessionAPI :),
our favorite topics.
Does this make sense? I was looking for the lowest common
denominator, for what a "cluster" is, essentially, nothing but a
group of VMs.
So what I try to do, is that the group wont be forced to expose
session state, cause if there is no state replication, you couldn't
implement that API.
Because I haven't thought much of the session API, as I do consider
that a higher level component, I haven't yet though of a good way,
if there is one, how that would sit on top of a cluster API. But I
do believe they shouldn't be morphed together, instead of the
SessionAPI must know about nodes and clusters, it would get that
from the cluster api, <ot>although i personally believe the session
api should only know about sessions and nothing else, but that is
why I am staying out of that topic :)</ot>
Filip
Greg Wilkins wrote:
This is my idea of how we could morph the currently proposed
session APIs
into a cluster API
I have created a spot for Cluster meta data - but I have not
filled it out much.
The key difference is that the state Map is now indexed by session
ID and context ID.
This allows the state for different contexts within the same
session to be on different
nodes (this is a real requirement) and also means that locking is
at context rather
than meta session level. Note that some implementations may not
fully support this and may just do sessionId+contextId behind the
scenes and colocate all context
states for the same session (and move them as one).
I have also added an async aspect to the API for potentially long
operations
such as moving state about the place - again this can be
optionally supported.
Also I support the idea of multiple Nodes per server (really
useful for testing
and heterogeneous clusters).
// The top level Cluster API - this was the Locator... but let's
call a spade a spade.
interface Cluster
{
// methods to get/set meta data about the cluster
// these signatures here are just a guess... but you get the
idea.
int getMaxNodes();
Set<Node> getKnownNodes();
void setKnownNodes(Set<Node> nodes);
Node getLocalNode();
// Access sessions in cluster. MetaSession
getMetaSession(String clientID);
Session createMetaSession(String sessionId);
}
// Node API
// was Server - but may have multiple Nodes per server
interface Node
{
String getName(); String[] getAddresses(String
protocol); void setAddresses(String string, String[]
strings); boolean isLocalServer();
boolean isActive();
int getPort(String protocol); // one way to handle the multi
nodes per server
int getPortOffset(); // or this one (add to standard
port)
}
// Meta Session - was SessionLocation
interface MetaSession
{
String getSessionId();
void invalidate();
void addEventListener(MetaSessionListener listener);
void removeEventListener(MetaSessionListener listener);
// State API has map per context ID , where a context
// ID might be "web:/context" or "ejb:" or random
boolean isStateLocal(String contextId);
Map getState(String contextId); // implies a move local!
void getStateAsync(Object key, String contextId); // async
version
Map createState(String contextId);
void releaseState(String contextId); // don't lock whole meta
session!
void invalidate(String contextId);
// Locaton / Policy API.
Node getNode(String contextId); Node getExecutionNode
(String contextId); void getExecutionNodeAsync(Object key,
String contextId);
// Don't know if these are too HTTP specific... but we need
them void setPassivationTimeout(long ms, String contextId);
void setInvalidationTimeout(long ms, String contextId);
}
interface MetaSessionListener
{
// callbacks to allow session manager to inspect contents
for // tier specific handling (eg servlet listeners etc.)
void activateState(String sessionId, String contextId, Map
state);
void passivateState(String sessionId, String contextId, Map
state);
void invalidateState(String sessionId, String contextId, Map
state);
// callbacks for async operations
void gotState(Object key, String sessionId, String contextId,
Map state);
void executionNode(Object key, String sessionId, String
contextId, Node location);
}
