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".
