On Sep 29, Peter Jasko quoth:
> The host+pid+time is fine for generating the odd id or two but it isn't
> fail-safe. In particular it can run into trouble if your system clock resets
> or if you create 100s or 1000s of beans a second, as most system time
> functions only resolve to 1 millisecond.
>
> I prefer the safer high/low pattern.
(this is becoming off topic, but sequence generation is an important issue
for people building distributed apps so I'll reply to you in the forum)
No matter how quickly the system generates beans, it can't outrun the
serial number which you neglected to notice. After all, that is the basis
of your high/low system, no?
Once you give up the constraint of attempting to generate integer
sequences and go instead to text strings, you can build robust (and
fail-safe) id mechanisms. Our only (loose) external requirement is to
have the system clocks synchronized. Even with a system clock reset we
only run into trouble if on that same host our process Ids match *and* we
seed the PRNG at the exact same time as a previous session *and* we happen
to request an ID at the exact same time as a previous request *and* we do
this at the same serial increment. While it isn't failure proof, for
being an idependent ID algorithm there is a high unlikelihood of
duplicate Ids.
While this is far from a formal analysis of the likelihood of failure, it
is very small for any reasonable usage whereas your algorithm has a
failure probability of 1 in the event of the high bit generator being
unavailable.
I would argue that while my mechanism has a very large probability of
generating safe Ids and is fail-safe within certain boundaries (ie very,
very, very, very unlikely to fail by generating an identical id even in
the event of time shifts), yours is completely fault-intolerant as when
your single point of failure--the high bit distributor becomes unavailble
you have no choice but to stop giving out sequence numbers. I don't know
about your application but in mine the existence of SP failures due to
design is not only unacceptable but suicide.
The use of serial sequence numbers is great if you have a limited key
domain, must give them out in order or must use all numbers in a sequence
to avoid gaps (e.g. you need to be able to account for all objects having
been given an Id). I would contend that applications needing these
features are less common than those simply needing unique identifiers.
Reduce system interdependency, don't add.
> -----Original Message-----
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED]]On Behalf Of
> [EMAIL PROTECTED]
> Sent: Thursday, September 28, 2000 10:00 AM
> To: jBoss
> Subject: Re: [jBoss-User] container generated primary key for CMP
> EntityEJB
>
>
> On Sep 28, Tom Cook quoth:
>
> > [EMAIL PROTECTED] writes:
> > > On Sep 27, Rickard Oberg quoth:
> > >
> > > For our application where we internally create our primary keys we
> aren't
> > > using a database feature to do so.
> >
> > How do you guarantee that they are unique across server instances?
>
> A GUID algorithm that allows for free-form strings that encapsulate the
> host generated on, the process space within that host, a serial number
> within that process, the time generated and a random number for good
> measure. (And before you ask, yes the time link with the random number
> seed has been taken into account, but it really exists there just as a
> feel good factor.)
>
> The distributed nature of our application requires that our database not
> be monolithic in nature and minimize data overlap. I.e. the space of all
> object instances spans several physical systems and databases separated
> geographically.
>
> C=)
>
> --------------------------------------------------------------------------
> There are no significant bugs in our released software that any significant
> number of users want fixed. -Bill Gates, Focus Magazine, Oct 23, 1995
> --------------------------------------------------------------------------
> Caskey <caskey*technocage.com> /// TechnoCage Inc.
> --------------------------------------------------------------------------
> "Welcome to the slippery slope, here is your handbasket.
> ...say, can you work 70 hours this week?"
>
>
>
> --
> --------------------------------------------------------------
> To subscribe: [EMAIL PROTECTED]
> To unsubscribe: [EMAIL PROTECTED]
> Problems?: [EMAIL PROTECTED]
>
>
>
> --
> --------------------------------------------------------------
> To subscribe: [EMAIL PROTECTED]
> To unsubscribe: [EMAIL PROTECTED]
> Problems?: [EMAIL PROTECTED]
>
>
--------------------------------------------------------------------------
There are no significant bugs in our released software that any significant
number of users want fixed. -Bill Gates, Focus Magazine, Oct 23, 1995
--------------------------------------------------------------------------
Caskey <caskey*technocage.com> /// TechnoCage Inc.
--------------------------------------------------------------------------
"Welcome to the slippery slope, here is your handbasket.
...say, can you work 70 hours this week?"
--
--------------------------------------------------------------
To subscribe: [EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
Problems?: [EMAIL PROTECTED]
