To get around the synchronization through a single resource, you can use a
batch protocol so that eaters of OID's get them in chunks. As long as you
don't care about "holes" in the OID's handed out, this works well.
-Chris.
> -----Original Message-----
> From: Tom Larson [SMTP:[EMAIL PROTECTED]]
> Sent: Friday, March 24, 2000 11:22 AM
> To: [EMAIL PROTECTED]
> Subject: Re: GuidFactory EJB
>
> 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".
===========================================================================
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".
