If I understand Greg's decision correctly, he made it to prevent a single
point of failure on the Orion server instance serving the key generation
with the counter.jar. That Orion server indeed is a single point of failure
instance as only one server should serve the key generation locally.
Of course, using the database as single point of failure is just a slight
shift of focus, but those beasts are usually a bit more stable thus I think
his decision probably improved the reliability of his system.
Ate
- Original Message -
From: elephantwalker [EMAIL PROTECTED]
To: Orion-Interest [EMAIL PROTECTED]
Sent: Monday, June 11, 2001 00:52
Subject: RE: clustering and key generation
Greg,
I didn't really understand your problem. If you are using counter.jar to
generate your keys, then the key is actually generated based upon the last
key in the database, not the appserver, so clustering shouldn't be a
problem. If there is an issue with transaction concurrency, you can always
hack the ejb-jar.xml for counter.jar to keep control of the transactions.
If you are using jdbc and a slsb (see Brett McGlauphlin's column on
Flashline.com), again the database is keeping track of the keys generated,
and not the appserver, so clustering shouldn't be a problem.
If you are using a bean (not an ejb, just anyolbean) to generate your
keys,
then you've got a problem with clustering...forget about this approach, it
will never work.
We use counter.jar, and have had no problems with key generation in a
clustered environment. Counter.jar is in the newsapp, and is freely
available for anybody to use.
Regards,
the elephantwalker
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]On Behalf Of Greg Matthews
Sent: Sunday, June 10, 2001 3:19 PM
To: Orion-Interest
Subject: Re: clustering and key generation
jason,
thankyou for yor responses.
in the interests of keeping it simple, i've decided to try to lobby
the rest of the team to go back to using db generated keys (i.e. identity
columns in the case of ms sql server ) and throw out key our
key generation code.
we'll then have a single .ear that can be deployed on any box
with minimal changes to 1 or 2 orion files to allow clustering, and
the only single point of failure will then be the database, and not
the box generating keys.
cheers,
greg.
- Original Message -
From: Jason Smith [EMAIL PROTECTED]
To: Orion-Interest [EMAIL PROTECTED]
Sent: Sunday, June 10, 2001 2:36 AM
Subject: RE: clustering and key generation
Have you tried setting:
ejb-module remote=true path=keygenerator /
in your orion-application.xml on machines B,C, and D? The only place
the
KeyGenerator bean is really deployed is on A, so machine A's
orion-application.xml will have remote=false. I am assuming you have
already set up your rmi.xml, etc. correctly to support this kind of
operation (as in the links I posted earlier).
The only other thing I can think of right now is maybe try making a
parent
application which has the KeyGenerator bean and run children apps on the
other machines. I haven't tried the parent/child app deployment, so you
would have to check the archives to see if this is feasible.
-jason
