Hello,
> 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?
This is the point about Java vs Corba I think. Let's speak about CORBA since
I have the idea clearer about this. I hope some RMI/JNDI guru can help us to
determine what would happen here.
A lookup for BeanBHome would return an IOR for NODE 2 (and node 1? to be
determined...
A lookup for BeanAHome would return a multi profile IOR targetting node 1, 2
and 3. Which node would be targetted first depend on the algorith on the
JNDI tree (algorith possibly set for each application differently)
> 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.
good point. (Hence the private/public JNDI tree suggested by Peter before I
guess.)
But here, I need more understanding about the cache mechanisme usage here.
If bean A, while receiving an invocation, stores some data in the tree, it
is highly probably that the "same" bean A on a different node will expect to
find such information at a later time, no?
Do you have any practical case in mind?
> 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 !?!
The client sees the cluster has a single entity. Why would data on one node
be unconsistent with data (from the same replicat) on another node? they
represent the same semantic?
> 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?
no you are right: the clustering should not be a problem, but a solution.
Any more practical sample would be appreciated!
Cheers,
Sacha
