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)
| Aaron Mulder <[EMAIL PROTECTED]>
10/18/2000 01:44 PM
|
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
On Wed, 18 Oct 2000, marc fleury wrote:
> why don't *we* provide the damn counter MBean (off by default) as a standard
> service of our platform (once and for all, gaddamit)
>
> I don't remember the thread so flame if you wish
>
> marc
>
>
> |-----Original Message-----
> |From: [EMAIL PROTECTED]
> |[mailto:[EMAIL PROTECTED]]On Behalf Of Aaron Mulder
> |Sent: Wednesday, October 18, 2000 8:26 AM
> |To: jBoss
> |Subject: Re: [jBoss-User] Re: [jBoss-User]
> |
> |
> | A Managed Bean. It's a JMX (Java Management eXtensions)
> |construct. Everything you load in the conf/jboss.conf file is an MBean,
> |so you can look at the implementations of some of those for ideas. This
> |is a big task, though, so you may be better served by just executing a
> |query against your DB to retrieve the next key (for example, "select
> |sequence.nextval from dual" on Oracle). That is, you may want to just do
> |that in your EJB. The MBean approach would be more generic (it could work
> |for a number of EJBs with independent key sequences), but more complex
> |too.
> |
> |Aaron
> |
> |On Wed, 18 Oct 2000, Bjarne Olsen wrote:
> |> Thanks for your answer, but what is an MBean ? (or just a typing
> |mistake?)
> |
> |
> |
> |--
> |--------------------------------------------------------------
> |To subscribe: [EMAIL PROTECTED]
> |To unsubscribe: [EMAIL PROTECTED]
> |Problems?: [EMAIL PROTECTED]
> |
> |
>
>
>
> --
> --------------------------------------------------------------
> To subscribe: [EMAIL PROTECTED]
> To unsubscribe: [EMAIL PROTECTED]
> Problems?: [EMAIL PROTECTED]
>
--
--------------------------------------------------------------
To subscribe: [EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
Problems?: [EMAIL PROTECTED]
