Hi!
> Well... we could certainly do that, but...
>
> 1) What data type? I would think Int and String would be the most common.
Use long, and then let the user stringify if necessary.
> 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).
This can be done quite easily by using an entitybean with option c caching
and a session bean that batch reads sequences of keys from the entity. Look
at the idgen in jbosstest for base implementation.
> 3) How do we avoid clashing with keys generated by the DB itself or other
> software?
By allowing the initial counter to be given. If you already have a bunch of
keys in the db then simply set the initial one to a number higher than
what's already created.
> 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.
Nah, a batched one would work just fine. Go see the discussion on this topic
on theserverside.com for inspiration.
> 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.
Db, yes, but a little more clever than having to update on each frickin
key...
/Rickard
--
--------------------------------------------------------------
To subscribe: [EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
Problems?: [EMAIL PROTECTED]
