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