Quick question,
=======================================================================
| 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 |
=======================================================================
EJB | | | |
SERVER | App1 running | App1 running | App1 running |
| App2 deployed but | App2 running | |
| in standby backup | | |
=======================================================================
If I make a lookup through JNDI and retrieve the BeanBHome from NODE 3, and
call create(),
will this return a stub to the application on NODE 2?
Also, the binding of EJB homes to JNDI, using IOR[] : I like what you are
saying. But I've seen a lot of developers that use JNDI as a regular object
cache. In this case you are dealing with serialized java objects, not IORs.
And name conflicts will occur.
A common solution to this problem is that the original binding will stay.
Take this example
=======================================================================
| 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.Cache |myapp.Cache | |
=======================================================================
EJB | | | |
SERVER | App1 running | App1 running | App1 running |
| App2 deployed but | App2 running | |
| in standby backup | | |
=======================================================================
CACHE | | | |
DATA | Data {A,B} | Data {B,C} | |
=======================================================================
In this case App1 uses the JNDI to store a local cache. BeanA is frequently
accessing this cache share data with other objects. Since no replication can
happen between NODE 1 and NODE 2 (name conflict) the serialized object in
NODE 1 and 2 are different.
Now node 2 goes down and clients that were previously connected to NODE
2-BeanA will get connected to NODE 1-BeanA.
But the data has changed - problems !?!
As you can see, the design of this "cache" idea is not good and would not
have been made by a senior engineer or architect.
But I have seen Java developers do this, and implementations like this do
exist.
Any thoughts on how that would impact the fact that the company that adopts
clustering already have an app developed and then wants adapt clustering.
Should they consider a redesign at this point, so that JBoss can "assume"
appropriate cluster design from the app level?
Filip
~
Namaste - I bow to the divine in you
~
Filip Hanik
Software Architect
[EMAIL PROTECTED]
www.filip.net
