Myles,
This is not necessary. Take a look at java.rmi.dgc.VMID.
Regards
Jose
Jeffery, Myles wrote:
> A cheap & chearful method of generating unique keys is to use the UID
> generator that comes standard with the RMI package:
>
> java.rmi.server.UID
>
> You can hack the code to incorporate the machine's IP address too for
> uniqueness across clusters.
>
> The chances of a duplicate key are infinitely small.
>
> The only way to gaurantee a globally unique number is for everyone to tap in
> to a central UID server - but I don't know of any such thing existing.
>
> Myles
>
>> -----Original Message-----
>> From: Jack Ferrod [SMTP:[EMAIL PROTECTED]]
>> Sent: 06 February 2001 08:59
>> To: [EMAIL PROTECTED]
>> Subject: Re: Autonumber primary keys
>>
>> Why not take the optimistic approach?
>>
>> Get a some sort of a random primary key that you think has a big chance of
>> being unique.
>> Try to insert that into the database. If it gets you a Duplicate Key
>> Exception, just regenerate the key and try to insert again. If your
>> randomizer is good enough, the chance of having to reinsert is very small,
>> so most likely this will perform better than most suggested options.
>> Also, the outcome will alway be guaranteed to be unique with respect to
>> the other records in the database.
>>
>> JF
>>
>> On Mon, 5 Feb 2001 21:01:44 -0500, Jay Walters <[EMAIL PROTECTED]>
>> wrote:
>>
>>> I will add my two cents...
>>>
>>> Consider how important portability between databases is to you before you
>>> rule out leveraging the database's ability to generate your keys.
>>
>> Sometimes
>>
>>> you need it really bad and need to be portable to a database which
>>
>> doesn't
>>
>>> have this feature, then you need to build the beans. This is
>>
>> particularly
>>
>>> true if you are building a product. Usually database portability for
>>> internal systems turns out to be a red herring. Imagine the operations
>>> people writing database independent scripts. Try optimizing an
>>
>> application
>>
>>> in a portable fashion. I just ported the product from SQL Server to
>>
>> Oracle,
>>
>>> do I need to test that?
>>>
>>> The major database vendors have been doing this for a while, and they
>>
>> have
>>
>>> scalable solutions to the problem.
>>>
>>> I've also seen some very elegant solutions in terms of very long primary
>>> keys which are galacticly unique, sort of like UUIDs. These are very
>>
>> nice
>>
>>> and will serve you well if there are issues about your company buying
>>> another company and your database schemas are 100% compatible. This is
>>
>> not
>>
>>> to mention how efficient it will be to store these monsters in memory. I
>>> know it's cheap, but it's not free. Some nice int's will probably work
>>> quite fine.
>>>
>>> Talk to the DBA. If you don't have a DBA, then God bless you.
>>>
>>> Cheers
>>> Jay Walters
>>>
>>>> -----Original Message-----
>>>> From: Kevin Gaasch [mailto:[EMAIL PROTECTED]]
>>>> Sent: Monday, February 05, 2001 2:52 PM
>>>> To: [EMAIL PROTECTED]
>>>> Subject: Autonumber primary keys
>>>>
>>>>
>>>> I would like to see everyone's suggestions on how to handle
>>>
>> Automatically
>>
>>>> generated primary keys. Utility objects, vendor specific, etc...
>>>>
>>>>
>>>> --------------------------------------------------
>>>> Kevin E. Gaasch
>>>> Anderson Merchandisers, Inc.
>>>> Java Application Development
>>>> Lotus Notes Development
>>>> [EMAIL PROTECTED]
>>>> (806)376-6251 ext. 4819
>>>> (800)999-0904 ext. 4819
>>>
>> ==========================================================================
>>
>>> 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".
>>
>
> ===========================================================================
> 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".
