If previous generations of pre-EJB technology are any guide, using the
vendor's sequence generator (where it exists) is definitely the most
performant way to go. If a particular CMP has problems with it, I believe
that the better persistence frameworks (e.g. TOPLink, CocoBase) will support
it.
BTW, one other design wrinkle to consider: if your business requirement is
for sequence numbers without gaps (e.g. check numbers), rather than merely
unique identifiers or an ordered sequence (gaps allowed), you are going to
have to settle for serialization (consider the case where A gets a number, B
gets a number, A's transaction rolls back, B's transaction commits...)
Carl Z.
> -----Original Message-----
> From: Laurel Neustadter [mailto:[EMAIL PROTECTED]]
> Sent: Monday, July 30, 2001 11:08 AM
> To: [EMAIL PROTECTED]
> Subject: Re: [EJB-INT] Sequence no generation
>
>
> Another potential solution:
>
> If the underlying DBMS supports auto-generated sequence
> numbers, design the
> entity's underlying table to have a field that is
> auto-generated. Pick up
> the sequence number in ejbPostCreate() and populate the
> instance field at
> that time. This may require BMP ... I don't know what happens if the
> CMP-generated SQL tries to insert a null into that auto sequence field
> (behavior is probably DBMS-dependent).
>
> Of course, this couples the bean to a particular DBMS vendor
> (or at least to
> vendors that support auto-generated sequence numbers). In
> practice, this
> doesn't seem to be a problem, since companies don't typically
> change their
> DBMS vendor willy-nilly.
>
> Comments?
>
> Laurel
>
> -----Original Message-----
> From: Avi Kivity [mailto:[EMAIL PROTECTED]]
> Sent: Monday, July 30, 2001 12:53 PM
> To: [EMAIL PROTECTED]
> Subject: Re: Sequence no generation
>
>
> >
> > OK, are you talking about the situation when the underlying
> > database doesn't
> > truly support serializable transactions (such as Oracle)? I
> > can see that
> > there would be a problem in this case.
> >
> > If the app server is using optimistic concurrency, the
> transaction is
> > running at the serializable isolation level, and the
> > underlying database
> > truly supports serializable transactions, it doesn't seem
> > there should be
> > problem.
>
> I'm no expert in database concurrency, here's how I see the database's
> options with two concurrent read-modify-writers:
>
> 1. Lock the second writer pending the first writer's commit.
> This is what
> Oracle does with read committed isolation level, and leads to data
> corruption and possibly deadlocks.
>
> 2. Lock the second reader pending the first writer's commit.
> No database
> corruption, but no concurrency either, high deadlock
> potential. This is what
> apps do when they use synchronize () naively.
>
> 3. Allow the second read -and- write to proceed, but rollback
> the second
> commit as it was based on stale data. This is what I believe
> Oracle does on
> serializable isolation. This isn't suitable for modifiable
> singletons - you
> will rollback very often.
>
>
> >
> > What alternative solutions do you see in the case where the
> underlying
> > database doesn't support serializable transactions, and
> > commit option A is
> > not viable?
> >
> > One option I see is for each server in the cluster to have
> a singleton
> > instance that hands out sequence numbers ... each singleton
> > instance grabs a
> > big block of serial numbers at a time. There still is the
> > potential for a
> > rollback exception to occur due to the optimistic
> concurrency, but the
> > singelton could be designed to deal with it via re-try logic.
>
> That sounds right. Of course, the database access should
> happen in its own
> transaction so that a rollback would not affect current work
> (it would also
> lessen the chances of such a rollback).
>
> >
> > Laurel
> >
> > -----Original Message-----
> > From: Avi Kivity [mailto:[EMAIL PROTECTED]]
> > Sent: Monday, July 30, 2001 11:48 AM
> > To: [EMAIL PROTECTED]
> > Subject: Re: Sequence no generation
> >
> >
> > You will get rollbacks in an optimisic concurrency scenario if two
> > transactions access the same sequence. Two transactions
> > read-modify-writing
> > the same row are essentially impossible to do concurrently
> (either may
> > abort).
> >
> > - Avi
> > --
> > This signature intentionally left blank.
> >
> > > -----Original Message-----
> > > From: Laurel Neustadter [mailto:[EMAIL PROTECTED]]
> > > Sent: Monday, July 30, 2001 19:10
> > > To: 'Avi Kivity'; [EMAIL PROTECTED]
> > > Subject: RE: Sequence no generation
> > >
> > >
> > > Hi Avi:
> > >
> > > It would still work ... you just use a different commit
> > > option (e.g., B or
> > > C), and an ejbLoad() is done at the beginning of each
> > transaction. The
> > > solution doesn't assume Commit Option A.
> > >
> > > Maybe I'm missing your point?
> > >
> > > Laurel
> > >
> > > -----Original Message-----
> > > From: Avi Kivity [mailto:[EMAIL PROTECTED]]
> > > Sent: Monday, July 30, 2001 10:58 AM
> > > To: [EMAIL PROTECTED]
> > > Subject: Re: Sequence no generation
> > >
> > >
> > > >
> > > > Why isn't it feasible to use an entity bean to hold the
> > > > sequence numbers?
> > > > One solution I have seen is as follows:
> > > >
> > > > DBMS has the following table (with some samle data filled in):
> > > >
> > > > EJB_ID || Next_Sequence_Number
> > > > ------------------------------
> > > > ACCT || 109
> > > > CAT_NO || 234511
> > > >
> > > > EJB_ID identifies the bean type that the sequence number is
> > > > for ... for
> > > > example, the next sequence number for account (ACCT) is 109,
> > > > and the next
> > > > sequence number for catalog item (CAT_ITEM) is 234511.
> > > >
> > > > You would then have an entity bean SequenceNumberGenerator
> > > > that maps to that
> > > > table. You don't have to worry about threads or
> > > concurrency, since the
> > > > container does that for you.
> > > >
> > >
> > > If your app server can guarantee exclusive locking for an
> > > entity, then this
> > > may well work (not concurrently, though - transactions will
> > > be effectively
> > > serialized). However, most app servers will not guarantee
> > > exclusivity in a
> > > clustered environment.
> > >
>
>
> - Avi
> --
> This signature intentionally left blank.
>
> ==============================================================
> =============
> 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".
