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