We have several orion's running in clustering, each of them serving up keys
from counter.jar, with no conflicts. Let me be clear, each orion instance
uses its own local counter.jar ejb to generate a key, but the underlying
data for the key generation comes from the database. The counter.jar is
called directly from a slsb, which then passes the generated key to the
entity bean create method. (We could have done this from within the entity
bean, it just seemed a little faster from the slsb). The slsb method to
create the entity bean is called from the web tier, a type II controller
servlet.
If one orion fails, then the other orion can take over, since the web tier
is clustered ....as is the loadbalancer's job. We have tested this
functionality, and it if we turn off one appserver, the other one takes over
the controller session without a problem.
You can directly use the database to create the keys from within the
controller servlet or a bean instanced in the controller, but then you do
not have any transaction control or any of those nice pooling things going
on under the hood with the app server, and you will pay for this with a
performance slowdown.
Brett McGlauphlin's series of articles on Flashline.com clearly indicates
the reasons for abstracting the key generation to the enterprise tier. I
would suggest a good read of this.
Regards,
the elephantwalker
-----Original Message-----
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]On Behalf Of Ate Douma
Sent: Sunday, June 10, 2001 6:05 PM
To: Orion-Interest
Subject: Re: clustering and key generation
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
> >
> >
> >
>
>
>
>
