[EMAIL PROTECTED] writes:
> You could avoid clashing with keys generated by the db by using a string
> type key with a prefix or suffix specific to jBoss, and avoid the
> clustering problem by using an additional prefix/suffix with a server
> identifer (hashed hostname, ip, whatever)
*sigh* haven't we had this flamewar? ;-)
That sort of key is never guaranteed to be unique, and is relatively
likely to be non-unique in certain situations (multi-threaded, high
load etc).
Tom
>
> Aaron Mulder <[EMAIL PROTECTED]>
> 10/18/2000 01:44 PM
> Please respond to jBoss
>
>
> To: jBoss <[EMAIL PROTECTED]>
> cc:
> Subject: RE: [jBoss-User] Re: [jBoss-User]
>
> Well... we could certainly do that, but...
>
> 1) What data type? I would think Int and String would be the most common.
> 2) How do we prevent ourselves from generating keys that have already been
> used? Especially when we move to a clustered environment, where each
> server would have the key generator service (unless handled carefully).
> 3) How do we avoid clashing with keys generated by the DB itself or other
> software?
>
> The most reasonable way would be to use the DB-specific
> key
> generation, but that only works for DBs that support it (Oracle and
> PostgreSQL, that I'm aware of), and would require user configuration (to
> pick a DB). I suppose we could make a "generic" setting that just uses a
> normal DB table, but it would have to just keep issuing SQL like "update
> foo set counter = (value+1) where counter=(value)" until one went through,
> to avoid clashing with other instances.
> Anyway, if you want me to go ahead and put such a thing
> together,
> say the word - any let me know if you can see a way to do it other than
> involving the DB.
>
> Aaron
--
--------------------------------------------------------------
To subscribe: [EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
Problems?: [EMAIL PROTECTED]
