Dave:
I think you either go with the three-part scheme and don't worry about counter
resets when the server shuts down, or you make the counter persistent and skip
the IP address & time-in-millis parts.
In the non-persistent solution, the counter only servers to differentiate
between two ids generated from the same IP address in the same millisecond.
Server restarts take more than a millisecond, so I think your covered.
However, I'm an advocate of the persistent counter object-id (OID) solution.
Understand that my bias may be partially due to my database background. However
here are some things to consider:
Your three-part, non-persistent oid will be large and end up polluting every
table (I'm assuming a relational datastore here) in your model.
Also, going with the "every object has an OID key" approach allows for a common
oversight -- humans often need to have a unique reference to an object. While
this doesn't have to be the OID, often times when using complex OID keys,
designers neglect to include the "human readable alternate key". When the
proper analysis and design does take place, you may end up with a large
system-generated OID, plus the human-usable key. This can become a significant
space issue -- I speak from painful experience here.
When an class doesn't have a natural and immutable primary key, the persistent
counter approach yields an OID that is a single number. That number will often
suffice as the human-usable reference.
Detractors may point out performance issues such as: single threading through
the persisted counter resource, but there are several techniques that we've used
to completely mitigate such issues. If there's interest, I can post some more
on the topic.
Tom Larson
Capital One Services, Inc.
5640 Cox Road, Mail Stop: 12013-0225
Glen Allen, VA 23060
804-934-8250 (voice)
804-934-2248 (fax)
[EMAIL PROTECTED]
-----Original Message-----
From: DaveFord <[EMAIL PROTECTED]>
Sent: Friday, March 24, 2000 7:20 AM
To: [EMAIL PROTECTED]
Subject: GuidFactory EJB
I want to create a GuidFactory EJB. It's purpose will be to generate unique
ID's for primary keys. The key will consist of:
IP address
current time in millis
a counter
The only state maintained by the EJB will be a counter. I don't want the
current value of the counter to be lost should the server shut down, so I
was thinking of using an entity bean. But since this will be a singleton,
there doesn't really need to be a "findByPrimaryKey" method.
So I guess my question is, how would you model this type of bean as an EJB.
Dave Ford
===========================================================================
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff EJB-INTEREST". For general help, send email to
[EMAIL PROTECTED] and include in the body of the message "help".
===========================================================================
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff EJB-INTEREST". For general help, send email to
[EMAIL PROTECTED] and include in the body of the message "help".
