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
> >
> >
> >
>
>
>
>
