i think elephantwalker's solution is probably better from a
database independence point of view and understand
now that counter works off the db.
i think using identity's is probably ok also, but we'll have
to do some OO stuff server side to abstract away the
"get the last identity used" (MS SQL SERVER) from
"get the next value from the sequence" (ORACLE).
cheers,
greg
----- Original Message -----
From: "elephantwalker" <[EMAIL PROTECTED]>
To: "Orion-Interest" <[EMAIL PROTECTED]>
Sent: Monday, June 11, 2001 1:24 PM
Subject: RE: clustering and key generation
> 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
> > >
> > >
> > >
> >
> >
> >
> >
>
>
>
>
