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
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
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
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
Re: clustering and key generation
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
AW: clustering and key generation
Hello. java.naming.factory.initial=com.evermind.server.rmi.RMIInitialContextFactory java.naming.security.principal=principal java.naming.security.credentials=credentials java.naming.provider.url=ormi://machineA/myApp this works when i run a standalone dos program to get a reference to KeyGeneratorBean on machineA, so why doesn't it work when the same code is run from inside an EJB on machineB? I had the same problem from inside an JSP page, and solved it by adding dedicated.connection=true to the properties. However, I'm not sure if this works from inside an EJB also. (see orion bugzilla bug #176 for this) /Thomas -- hybris GmbH | /Thomas Hertz Frankfurter Ring 162 | Software Engineering D-80807 München | | t +49(0)89 89065-0| [EMAIL PROTECTED] f +49(0)89 89065-555 | www.hybris.de PGP: D070 5D86 BE2D C3AF E2CC D2D8 C29A 7F68 7407 629E
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
clustering and key generation
dear all, if there any way to get all machines in a cluster to lookup a stateless session bean (KeyGeneratorBean) on *one* of the machines in the cluster only. i've given it a try but can't seem to find a way to get machine B to use machine A's KeyGeneratorBean, even though machine B builds a new InitialContext with the 4 environment parameters, e.g. principal/credentials/url/factory when doing a lookup for KeyBean. thanks, greg.
Re: clustering and key generation
hi, i had a read and i'm still stuck. my question specifically is about why the InitialContext i create for referencing a KeyGeneratorBean on another box doesn't work. machines A, B, C, and D each have the same app deployed, which has many beans. Each box should use it's own beans, except KeyGeneratorBean. I want to tell *all* boxes to use the KeyGeneratorBean on machine A. I do this by creating a new InitialContext that is used only when getting a home interface to KeyGeneratorBean, by calling the InitialContext( Hashtable) constructor, where Hashtable contains java.naming.factory.initial=com.evermind.server.rmi.RMIInitialContextFactory java.naming.security.principal=principal java.naming.security.credentials=credentials java.naming.provider.url=ormi://machineA/myApp this works when i run a standalone dos program to get a reference to KeyGeneratorBean on machineA, so why doesn't it work when the same code is run from inside an EJB on machineB? any help much appreciated, greg. - Original Message - From: Jason Smith [EMAIL PROTECTED] To: Orion-Interest [EMAIL PROTECTED] Sent: Friday, June 08, 2001 2:04 PM Subject: RE: clustering and key generation These posts in the archive may help you (although they target Orion web server-Orion ejb server configuration instead of a cluster). http://www.mail-archive.com/orion-interest@orionserver.com/msg12704.html http://www.mail-archive.com/orion-interest@orionserver.com/msg11905.html -jason -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Greg Matthews Sent: Thursday, June 07, 2001 10:19 PM To: Orion-Interest Subject: clustering and key generation dear all, if there any way to get all machines in a cluster to lookup a stateless session bean (KeyGeneratorBean) on *one* of the machines in the cluster only. i've given it a try but can't seem to find a way to get machine B to use machine A's KeyGeneratorBean, even though machine B builds a new InitialContext with the 4 environment parameters, e.g. principal/credentials/url/factory when doing a lookup for KeyBean. thanks, greg.
RE: clustering and key generation
These posts in the archive may help you (although they target Orion web server-Orion ejb server configuration instead of a cluster). http://www.mail-archive.com/orion-interest@orionserver.com/msg12704.html http://www.mail-archive.com/orion-interest@orionserver.com/msg11905.html -jason -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Greg Matthews Sent: Thursday, June 07, 2001 10:19 PM To: Orion-Interest Subject: clustering and key generation dear all, if there any way to get all machines in a cluster to lookup a stateless session bean (KeyGeneratorBean) on *one* of the machines in the cluster only. i've given it a try but can't seem to find a way to get machine B to use machine A's KeyGeneratorBean, even though machine B builds a new InitialContext with the 4 environment parameters, e.g. principal/credentials/url/factory when doing a lookup for KeyBean. thanks, greg.
