Thanks, Jay, for answering Laurel's question.
I'm unclear, though, about the "tip". My suggestion was to do the read with
lock (FOR UPDATE) and then do the update followed by a commit. Is there's a
reason to do an additional read? I can't think of one. A read has to
precede the update in order to get the current (or next) value. If that
read locks the row, and the update happens in the same transaction as the
read with lock, then I think we're covered.
Wait, maybe I do get it. Are you saying that you could do the update then
the read -- the reverse of my example? Yep, this would work equally well,
again assuming both happened in a single transaction.
-Tom
-----Original Message-----
From: Jay Walters [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, July 31, 2001 7:07 PM
To: [EMAIL PROTECTED]
Subject: Re: Sequence no generation
The select nextval from the oracle sequence doesn't have to be last as it
doesn't lock the sequence to select the nextval from it - as Tom said it's
not part of the transaction.
Another tip, if for some reason you're just using a database table with a
column that is your next value, always update and then read to ensure it's
locked. Of course this won't scale which is why you should always try and
use the vendor specific way to generate a simple increasing key value.
Cheers
-----Original Message-----
From: Laurel Neustadter
To: [EMAIL PROTECTED]
Sent: 7/31/01 5:16 PM
Subject: Re: Sequence no generation
Hi Tom:
Is using Oracle sequences ("SELECT MYSEQUENCE.NEXTVAL FROM DUAL") an
alternative to the factory implementation? That is, do you use one or
the
other for a given entity bean? I'm not sure if you are saying you used
both
in conjunction with one another in your last paragraph. (I think I
understand using one or the other, but I don't grasp how they would be
used
together.)
Also, in the case of using Oracle sequences, is it still important that
the
select be in a different transaction from the transaction that the
entity
bean is being created in?
Thanks.
Laurel
-----Original Message-----
From: Larson, Tom [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, July 31, 2001 3:27 PM
To: [EMAIL PROTECTED]
Subject: Re: Sequence no generation
Here's a simpler variant on Jay's suggestion.
First, though, some constraints and other thoughts:
1. As noted by another writer, if you need a contiguous sequence, you'll
be
serializing your inserts. There's is no way around this, period.
However,
you may be able to get reasonable performance if you make the fetch and
update of the central sequence the very last operation in your database
transaction. (This minimizes the lock time on the serialized resource)
2. The sequence number generation factory (regardless of it's
implementation) must operate in a different transaction than the clients
of
the factory. NOTE: If you're using Oracle native sequences (and I
strongly
suggest you do if you're in an Oracle environment) then this is not an
issue, because updates to the sequence are not transactional.
3. Many CMP containers will offer a solution -- sometime multiple
solutions
-- to this problem. You should investigate these first, if they're
available to you, and use them if they're acceptable.
The factory implementation:
The factory can be a singleton but it doesn't have to be. The solution
works equally well with multiple factory instances, so a networked
singleton
would be overkill. The factory (or factories) essentially cache some
number
of values from the persistent sequence. So, using a table-based
sequence,
the factory would first execute the following SQL:
SELECT CURRENT_VALUE FROM SEQUENCE_TABLE FOR UPDATE;
UPDATE SEQUENCE_TABLE SET CURRENT_VALUE=VALUE+100;
COMMIT;
At this point the factory object would "own" 100 values that it could
dole
out one at a time. When the 100 values are depleted, the SQL above is
repeated. Obviously, the "100" value is tunable. Higher settings yield
fewer trips to the DB, but also will waste more numbers when factories
are
destroyed. Even with wastage, our analysis showed far smaller average
key
sizes (numbers) when compared to techniques that concatenated two
values, or
were time-based. You mileage may vary, blah, blah, blah.
I used this solution a few years back on a non-EJB project and it worked
very nicely. We did use Oracle sequences (SQL becomes "SELECT
MYSEQUENCE.NEXTVAL FROM DUAL") and used both the databases-level
sequence
number caching and the application-level mechanism described above. It
performed so well that the cost of primary key generation was lost in
the
noise of the overall performance metrics.
Tom Larson
Capital One Financial
-----Original Message-----
From: Jay Walters [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, July 31, 2001 10:11 AM
To: [EMAIL PROTECTED]
Subject: Re: Sequence no generation
Check out something like the hi/low generator pattern. I think it's
more
likely used with session beans, but each instance takes a high value
from a
central store like a database and then generates a low value for each
request. When you put together the two values it's unique.
If you use BMP you can just do the sequence stuff in ejbCreate no muss
no
fuss, but of course there are other issues when making the switch from
CMP
-> BMP.
Cheers
-----Original Message-----
From: John Bateman
To: [EMAIL PROTECTED]
Sent: 7/31/01 9:48 AM
Subject: Re: Sequence no generation
Hi
Just read Avi's post on "Do BMP's buy you anything".
I think I get it now, the sharing model of the "seq number" is what
actually
makes is infeasible to use EB's because multiple calls to 'get next
number'
could return the same number since the Entity Bean isn't 'shared' but
has a
pool. I.E. Each call has a handle to some object in the pool. these
object
would represent the same state of the 'seq numbers'.
>
> Hi
>
> How does a stateless Session bean guarantee that the data is
> always fresh?
> Also since these sequence numbers are pretty much the
> intermediate state of
> a data model between calls, doesn't this just scream "Entity Bean"?
>
> I know the following is an ongoing discussion on the net,
> but, I'll take the
> angle that I could use simple CMP and some sort of a
> singleton handing out
> the 'next' number. Even large requests would be minimal to
> 'get acctountNo +
> 1' and then set the change to the entity bean.
>
> Using this 'design' wouldn't I almost be guaranteed that the
> bean always has
> fresh data? Additionally the 'new' seq number could be mapped to the
> database at any time so that any external acces to the DB
> could use the same
> numbers too?
>
> I'm relatively new to the proper in's and out's of this
> architecture so I
> tend to have some misconceptions about it's abilities. Please
> excuse me if
> I'm overlooking some simple point here.
>
> (As an aside I'm not even looking at the effects of all this
> in a clustered
> environment.. which I'm learning seems to be a headache to
> maintain data
> state.)
>
> Thanks.
========================================================================
===
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".
************************************************************************
**
The Information transmitted herewith is sensitive information intended
only
for use to the individual or entity to which it is addressed. If the
reader
of this message is not the intended recipient, you are hereby notified
that
any review, retransmission, dissemination, distribution, copying or
other
use of, or taking of any action in reliance upon, this information is
strictly prohibited. If you have received this communication in error,
please contact the sender and delete the material from your computer.
========================================================================
===
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".
**************************************************************************
The Information transmitted herewith is sensitive information intended only
for use to the individual or entity to which it is addressed. If the reader
of this message is not the intended recipient, you are hereby notified that
any review, retransmission, dissemination, distribution, copying or other
use of, or taking of any action in reliance upon, this information is
strictly prohibited. If you have received this communication in error,
please contact the sender and delete the material from your computer.
===========================================================================
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".
