Andrew,
This is not for EJB clustering, it is for clustering a database. You can
control which "data-base" is used for a specific cmp bean. You can do this
at deploy time with the orion-ejb-jar.xml. So if you have three different
deployments of the bean in different applications, each one can point to a
different data-base...one for oracle, one for postgresql, and one for
sybase. Or you can point to different oracle databases on different
machines, one for each of the beans. Its up to you.
This is not about EJB clustering. If you want to cluster EJBs, you will have
to use RMI clustering. See the RMI.xml documentation. With RMI clustering
you will get fail-over on EJB. That-is, if one server stops responding,
orion will go to the next server in the RMI cluster. This is useful if you
have beans my_got_to_be_available.jar deployed on machines A, B and C, and
web-containers www1 and www2 are using REMOTE access to the this bean. If
you setup the rmi cluster on A, B, and C...if www1 is accessing the bean on
A, but A goes down, www1 will automatically go to the next one on the list,
B.
As for load-balancing EJBs in a cluster, orion only has the simplest of all.
You can limit the number of beans deployed on a server. If the servers are
RMI clustered, then when server A has met its limit, RMI will go to server
B. Not really load-balancing...but it works.
It would be nice if someone responded with hard testing on these advanced
capabilities. That's not really load-balancing, but its what is available on
Orion. If all of the methods are transaction controlled, you will get
roll-backs from the container when a remote server goes down. So no data is
corrupted.
I am hopeful that the Orion team is working on true ejb clustering in the
future. I think that there is a blurb on the Oracle site indicating that
they are working on this...but don't hold me to that one.
As a matter of course, Orion is usually deployed with the whole shebang on
the same server, web-container and enterprise container. If the
web-container is clustered and loadbalanced, if one server goes down,
another server will take over...but the ejb references will be lost. You can
code for this eventuality by always checking if you Remote or Home
references are null before using them, and if they are...just redoing the
reference calls. Its unfortunate that the <distributable /> tag in the
web.xml file doesn't enforce this coding style, but who can? ;). Stateful
Session Beans are a definite no-no in a clustered application.
Regards,
the elephantwalker
-----Original Message-----
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]On Behalf Of Andrew Chau
Sent: Wednesday, July 25, 2001 8:21 AM
To: Orion-Interest
Subject: schema-clustering
I am in the process of implementing our CMP EJB cluster using Orion
1.5.2.
However, I couldn't find any documentation detailing how to do this.
Orion 1.5.2 claims support for EJB clustering, I think it is primary
aimed to solve the CMP Entity EJB cache sync problem.
Howeve, as you might have noticed, there is no documentation whatsoever.
There is a new feature called schema-clustering, and searching thru
their entire document tree, their support website and the whole net
only turns back one sentence...
clustering-schema - The name of the data-source used if using
container-managed persistence.
This is a new tag used in the orion-ejb.jar.xml at deployment time.
I think it is used to tell all the CMP Entity EJB server to map
to the same data source and the whenever their data in cache change, a
async message is broadcast to everyone in the cluster.
Any server receiving the message should invalidate that data in their
cache and reload it fresh from the database the next time
that data is referenced.
Please correct me if my assumption here is wrong. Does anyone have more
info on this?
Thank you very much in advance.
Andrew
