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