Hello,
David B. kindly reminded me I should mention the SFSB clustering work
I am currently working on on the OpenEJB dev. list - so far, I only
mentioned this work on the Geronimo dev. list.
Firstly, apology for only mentioning this work now.
Now, let me talk a little bit of this work: I will soon add support
for the clustering of SFSB. By now, this clustering is only available
with OpenEJB embedded within Geronimo. It should be easy to have this
feature available with the standalone OpenEJB container by moving
across an upcoming Geronimo sub-project to a new OpenEJB sub-project.
For the history, my initial attempt had clustering classes in openejb-
core and I discovered these clustering classes should be packaged in
a separate JAR for class loading reasons - it was not such a big
surprise.
The clustering of SFSB is based on the same approach than for the
clustering of Jetty or Tomcat Web-applications over WADI: we add a
clustered SFSB container. When an EJB invocation enters this
container, it traverses a stack of WADI Contextualisers whose
responsibility is to locate the SFSB being invoked and ensure that
the invoked SFSB instance is available locally, i.e. in this JVM by
the SFSB instance manager. When the SFSB being invoked is on a remote
clustered SFSB container, it is first passivated on this remote
container and then activated on the container processing the EJB
invocation.
When an EJB client initially performs a remote JNDI lookup for a SFSB
deployed to the clustered SFSB container, it connects to the
configured Context.PROVIDER_URL. In the case of a successful lookup,
the JNDI response contains the locations, e.g. [ejbd://localhost:
4201, ejbd://localhost:4202], of the clustered SFSB containers
running the looked up SFSB. Based on these locations, the client
knows where the SFSB is currently running and, hence, it can fail-
over to another clustered SFSB container if the "primary" container
becomes unavailable. On each EJB invocations, an updated list of
locations may be returned with EJB responses if client locations
differ from server-side ones. The server knows that it needs to
provide an updated list of locations based on a non collision free
integer derived from client locations which is attached to each EJB
invocations.
Clustered SFSB instances are replicated as per the same approach than
for HTTPSessions in the case of Jetty or Tomcat Web-applications:
configure the number of replicas to be maintained. As for
HTTPSessions, it is possible to only replicate field level changes by
leveraging the wadi-aop module.
I will ping the list once again when my integration tests are
completed. Meanwhile, if there are any concerns, then please feel
free to raise them.
Thanks,
Gianny
