Hi!
> On Wed, 18 Oct 2000, Rickard Oberg wrote:
> > > 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.
>
> I disagree. I don't think we should assume that jBoss is the only
> user of the database. In general, I think we have to assume that other
> apps may be updating at the same time, and even triggers within the DB and
> so on.
I am not assuming that jBoss will be the only user of the DB. In fact, by
saying that we should use commit option c it
s quite the contrary.
> Now, with a compliant DB, we can fetch a number of values all in a
> row instead of one at a time as requests come in, but I don't think that
> really buys you anything. In that case, we're not getting a range, just
> calling "nextval" 10 times in a row.
No I am not suggesting that. Please see the idgen beans in the jbosstest
module.
> Ah - perhaps you were just talking about the non-compliant DB,
> where we have to fake it by writing our own table or something. In that
> case, then you could certainly grab a bunch of IDs at once by just upping
> the "last value" by 10.
Yes, a table with basically two columns: bean name and last used id. Each
batch use will up the id field by 10 or 100 or something.
> I think it would be better to do this as an MBean instead of an
> EJB, though - it's really a service of the server, not a co-existing app
> which has security and transaction settings and so on.
Well, using a table to do it would need transactionality. It's not that much
of an overhead all in all. Using an MBean would be worse I think since you
would have to use RMI to talk to it through a connector. EJB talk we can
optimize.
> And I kind of
> liked the suggestion that you just look in JNDI under "system/nextID" or
> whatever and get back the next ID directly... Saves you from dealing with
> all that factory crap... :)
That can easily be hidden away in a JavaBean that does the idgen
interaction. That is precisely one of the reasons they chose a naming system
that can easily be accessed without having the bean "give" the naming to the
underlying libraries. A library can always do new
InitialContext().lookup("java:comp/env") and get the conf stuff.
/Rickard
--
--------------------------------------------------------------
To subscribe: [EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
Problems?: [EMAIL PROTECTED]
