So this is the scenario where information could be shared in the JNDI tree
for other purposes than just storing references to home interfaces.
=======================================================================
| NODE 1 | NODE 2 | NODE3 |
=======================================================================
JNDI |App1/BeanAHome |App1/BeanAHome |App1/BeanAHome |
SPACE |App1/BeanA |App1/BeanA |App1/BeanA |
|App2/BeanBHome |App2/BeanBHome |App2/BeanBHome |
|App2/BeanB |App2/BeanB |App2/BeanB |
|myapp.Snapshot |myapp.Snapshot | |
=======================================================================
EJB | | | |
SERVER | App1 running | App1 running | App1 running |
| App2 deployed but | App2 running | |
| in standby backup | | |
=======================================================================
CACHE | | | |
DATA | Data {A,B} | Data {B,C} | Data {D,E} |
=======================================================================
I have made a monitor system built into my app. This monitor system consist
of an internal measurement/snapshot component that sits inside the EJB
application and an external report/analysis component.
The internal snapshot component gathers information about the EJB app
statistics and publishes them into an object into the JNDI tree.
In a non-clustered environment, the external report/analysis component will
go to each server and take the latest snap shot and compile the information
and produce a report. The snapshot is bound to the name myapp.Snapshot.
So far so good, the monitoring works great with my 3 different server nodes.
No client transparent fail-over has become a requirement from the EJB client
app (another app that accesses the EJB server, not the monitor report app).
The developers thought they could do this seamlessly, but as it turns out,
all the content in the JNDI tree gets replicated between the cluster nodes.
This means that object bound to the name "myapp.Snapshot" represents the
latest snapshot of each of the individual servers. But what happens if NODE
2 gets restarted, and a snapshot has not been performed (bound to the JNDI
tree)? Now there is a risk that a snapshot from NODE 1 or 3 gets replicated
into the JNDI tree of NODE 2 and the report component is accessing incorrect
data.
Also, lets say that the client is reading snapshot data as well and
collecting a history on client machine, so when NODE 2 fails, the request
gets automatically redirected to NODE 1 and the client data doesn't make
sense anymore :)
Now this is clearly a design that was not made with clustering (shared JNDI
contexts) in mind.
But it happens, and they probably already exist.
We could say, "hey dude, you should have thought of clustering at the time
you designed your report monitor" and the guy will reply
"well, there wasn't a clustering strategy in place for JBoss when I designed
my app, I had no idea that the JNDI context would replicate everything into
other server nodes."
Although this example is clearly not anything I would do (I know better than
to use JNDI for shared caching :) I'm sure similar scenarios actually do
exist.
Just trying to point out two things here
1. You will have name conflicts when replicating JNDI objects
2. If you have a strategy of resolving those name conflicts by applying some
FIFO overwrite rule, you may end up overwriting data that applications
depend upon.
3. When a client gets transparently redirected to another NODE, they may see
unexpected data in the JNDI tree from what they say in their previous call
One way to do clustering if you have an app like this is to use NODE 1 as
main server and NODE 2 as hot standby, ie no clients connect to NODE 2 until
NODE 1 crashes. this way the transparent failover is truly transparent
just some thoughts on JNDI replication issues
Filip
~
Namaste - I bow to the divine in you
~
Filip Hanik
Software Architect
[EMAIL PROTECTED]
www.filip.net
