Agreed, VMID already combines a UID and the IP address.
> -----Original Message-----
> From: Jose González Gómez [SMTP:[EMAIL PROTECTED]]
> Sent: 06 February 2001 09:30
> To: [EMAIL PROTECTED]
> Subject: Re: Autonumber primary keys
>
> 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".
>
===========================================================================
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".
