I think, therefore I exist -- Rene Descartes
I think, therefore I exist -- Rene Descartes
[OCP 21 Professional Study Guide] [OCP 17 Complete Study Guide] [OCP 17 Practice Tests] [OCP 11 Complete Study Guide] [OCP 11 Programmer I] [OCP 11 Programmer II] [OCP 11 Practice Tests] [OCA 8] [OCP 8] [OCP 8 Practice Tests Book] [Blog]
For example, give each machine (or JVM) a name (or better an id) so that the full key for a record is (machineId,UniqueId) such as ('server1',3401). This is guaranteed to be unique since each JVM has its own name. This solution has some additional advantages such as it now allows you to merge data in distributed systems easily. For example, you can have multiple de-synched machines that can combine their data easily for inserts without having to re-organize keys.
Remember, the only rule for keys is that they need to be unique, other than that they can be whatever you want.
And for completeness, you can use a singleton-like solution that avoid using a 2-key solution with multiple JVMs by setting up an EJB service that runs in one JVM. In fact, give it its own JVM if you plan to cluster. Some application servers, WebSphere for example, will optimize calls for all local servers so you will still get speeds similar to that of a singleton object.
I think, therefore I exist -- Rene Descartes
[OCP 21 Professional Study Guide] [OCP 17 Complete Study Guide] [OCP 17 Practice Tests] [OCP 11 Complete Study Guide] [OCP 11 Programmer I] [OCP 11 Programmer II] [OCP 11 Practice Tests] [OCA 8] [OCP 8] [OCP 8 Practice Tests Book] [Blog]
A good question is never answered. It is not a bolt to be tightened into place but a seed to be planted and to bear more seed toward the hope of greening the landscape of the idea. John Ciardi
Going to the database for every key is too expensive, but relying on in-memory sequences is unreliable. So ...
We use a two-part key. Each server gets the first part from the database, then builds the second part from 1 to 999. Then it goes to the database for another first part. I'm pretty sure I got this idea from a Scott Ambler article.
Another approach is to use a single part key but reserve a range. So instead of incrementing the next available key on the database by 1, a server might increment the next available key by 1000. Then it could use 1000 in-memory seqeuence numbers before going to the database again.
Both of these result in missing sequence numbers in the database. Every time we stop a server we throw away 500 keys (on average). This may or may not be an issue for you.
Your example about jvm crashing is a completely different issue, the jvm should use some level of pre-fetching and store this information in the database. For example, it should request ids from 1-100 (the database would store 100), then 100-200, etc so that it does not constantly have to connect to the db. At the center, the ids would still be generated in numeric order (a very common practice).
Less overhead and more portability to answer your general question. I don't like solutions that are EJB server-dependent, they are contrary to the some of the principals of J2EE.
I think, therefore I exist -- Rene Descartes
I think, therefore I exist -- Rene Descartes
Originally posted by Valentin Tanase:
Well different people might think different (ultimately we are all so different though :-), but the ideal of using pure J2EE solutions and not involving container specific technologies at all is in my opinion rather silly.
They deliberately contradict the J2EE build one run everywhere paradigm (which in my opinion has lot of theoretical value but not much practical appeal) and provide guidelines for improving your application within the environment you�re using.
Would you simply ignore all of these practice and tehniques only because J2EE tells you otherwise?
[OCP 21 Professional Study Guide] [OCP 17 Complete Study Guide] [OCP 17 Practice Tests] [OCP 11 Complete Study Guide] [OCP 11 Programmer I] [OCP 11 Programmer II] [OCP 11 Practice Tests] [OCA 8] [OCP 8] [OCP 8 Practice Tests Book] [Blog]
Another approach is to use a single part key but reserve a range. So instead of incrementing the next available key on the database by 1, a server might increment the next available key by 1000. Then it could use 1000 in-memory seqeuence numbers before going to the database again.
Look ma! I'm selling my stuff!
Smokeless wood heat with a rocket mass heater
https://woodheat.net
|