Hi!
As far as I know, Orion does not support EJB tier clustering (only web
clustering). Meaning: there is no auto-failover calls to an EJB in another
server in a cluster and there is no state replication for stateful EJBs,
etc. However, there is no reason why you can't wrap your calls to EJBs to
make calling different servers transparent to client code. In the process, u
can take advantage of some of Orion's features to make this possible.
To be honest with you... I have not tried this, but here it goes!
Clustering EJBs in Orion
---
1.) Wrap all calls to EJBs in a class that checks for success/failure of the
call and can retry on another server (psuedo code below).
2.) When there is a failure, how do you contact another server? Answer:
Orion's InitialContextFactory implementations have the ability to add
multiple hosts into the URL. Documentation from the Orion API
RMIInitialContextFactory goes something like this:
"java.naming.provider.url - The target URL, it's format is:
[http:|https:]ormi://hostname/applicationname. Prefixing with http: or
https: enables http(s) tunneling. It is possible to supply multiple hosts
(for failover) by using a comma-seperated list. For instance
ormi://first.server.com,ormi://second.server.com."
I believe this gives you automatic failover for initial context lookups at
least.
psuedo code:
while (numOfTries 3) {
try {
numOfTries++;
Context ctx = getMyInitialContext();
// ctx to serverA first time, if serverA is dead, returns context to
serverB, etc.
myEJBHome home = (myEJBHome)ctx.lookup("myEJBHome");
myEJB bean = home.create();
numOfTries = 4; //get out of loop
}
catch(RemoteException ex) {
// loop back, get an initial context to another server, and try again!
}
}
I suggest encapsulating this logic in a Command pattern.
3.) If everything is stateless, you are fine. If you are using entity
beans, then you'll have to configure some stuff to make sure state is
handled correctly and you are always looking at the freshest data.
For entities, in the orion-ejb-jar.xml descriptor, set your attribute for
"exclusive-write-access=false" to force Orion to go back to the database to
reload the entity bean. Otherwise, flush the cache as specified in another
thread on this discussion group. Going back to the DB everytime is how many
J2EE servers handle clustered entitybeans including WebLogic. So don't feel
this is too much of a hack.
4.) TODO: Figure out a load-balancing scheme. The InitialContext scheme I
mentioned is really only a failover option. It always contacts the first
server in the URL, then the next if it fails.
Anybody have time to guinea pig this solution? Anybody see holes in it?
Open for suggestion.
Jason
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]On Behalf Of Dylan Parker
Sent: Wednesday, February 21, 2001 11:33 AM
To: Orion-Interest
Subject: EJB Clustering -- ANYONE? [Urgent!]
Importance: High
Hello, all.
My company is about to drop Orion.
The documentation issues, the dead website, the documentation issues,
the absence of company responses, the documentation issues...
We've contacted them asking where to send our money. Nothing back.
In one last futile attempt to keep Orion afloat in my company a little
longer, can anyone provide me with the following information?
How does one do EJB Clustering with Orion?
Has anyone made this work?
Can anyone give some background on the configuration steps?
If I don't hear anything... then JRun, here we come.
Thanks,
Dylan Parker
