I think my questions really revolve around using Oracle
in an ejb environment. If you are using container
managed persistence with ejb's, you don't have any
explicit access ot setting locks, or reading database
sequence numbers, etc. So, my thinking has been,
you have to use serializable isolation, there's nothing
else.
Then, I started poking around, and I hear people telling
me to avoid Oracle's serializable isolation at all costs.
This has been leading me to believe that people simply
don't use Oracle for ejb's with container managed
persistence. Either that, or there is some nifty algorithm
for doing reliable data integrity using Read-Committed
isolation.....
Personally, I have no problem dealing with the
Oracle's optimistic concurrency. I think it is a good
approach, and in the end will be the most efficient.
This I know from my background designing multi-threaded
concurrent algorithms....
The simple issue is just the need to be able to handle
the "could not serialize access" error. As I mentioned
in another thread, the ejb spec needs to add an
exception type, sub-classed from RemoteException, called:
TransactionSerializationException
This would be a portable exception which could be caught,
in which the transaction should be retried.
Furthermore, it would be great if the container could be
configured to automatically retry the transaction (assuming
there are no issues with respect to repeatability for the
specific transaction in question). Perhaps, there should
be an added transaction attribute called:
TX_SERIALIZABLE_AUTO_RETRY
Jason
----- Original Message -----
From: "Victor Langelo" <[EMAIL PROTECTED]>
To: "Jason Rosenberg" <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>
Sent: Thursday, August 03, 2000 10:59 AM
Subject: Re: Read-Committed Isolation Level
> Jason Rosenberg wrote:
>
> > Since it is becoming more and more clear to me that most people
> > using WebLogic with Oracle do not use an isolation of SERIALIZABLE,
> > I am trying to understand how to use READ-COMMITTED isolation.
> > Does anyone use SERIALIZABLE? What do you do with the
> > "could not serialize access" errors?
>
> We use serializable where appropriate. We're using Weblogic, JRun and
other
> containers. What do we do with the "could not serialize errors?" Good
question.
> Mostly we tell the user to try again. Sometimes it's appropriate to retry
> automatically. Since we use optimistic concurrency control a lot, the user
could
> see similar problems with any transaction. There are no great solutions.
We are
> working on a UI for presenting a view of the difference between what the
user
> modified and what someone else modified and allowing then to reconcile the
> difference. No easy answers here.
>
> >
> > For example, assume I am trying to implement a counter, which
> > counts the number of time the entity field is updated, by having
> > its value incremented each time the method is called.
> >
> > Certainly, if 2 transactions are using READ-COMMITTED, they
> > could both read the same current value, and then try to write the
> > same new value.
>
> Correct. Serializable might be appropriate here depending on the length
and
> breadth of the transaction.
>
> >
> >
> > My question is, what happens at this point? Assume the first
> > transaction successfully writes and commits an incremented
> > value for the counter. What happens with the other transaction.
> > Is it locked out while the other is writing and committing?
>
> In most DBMS which support locks, it will wait between the write and the
commit.
>
> > Won't
> > it still try to write the same value again, instead of the next value
> > in the sequence? Are there any exceptions thrown?
>
> Yes it will write the same value again. No exceptions. It's not really an
error
> unless the transaction is Serializable.
>
> >
> >
> > Is this just not something that people implemented with
> > READ-COMMITTED?
>
> I use Oracle's sequences for simple unique keys. For counters, you can
place the
> code for the counter in a separate serializable transaction. This reduces
the
> chances of an exception.
>
> Oracle also supports the ability to lock the record when it is read. This
> feature along with the ability to throw an error when attempting to access
a
> lock record, will prevent the problem you mention without having to use
> Serializable. But it cannot be implemented in a portable way. In fact, I
don't
> believe it's even support in JDBC drivers. This is what Serializable
should
> probably do, but then you get into the whole deadlock issue. Oracle's
approach
> is a compromise that pleases few.
>
> >
> >
> > Jason
> > "Building Trust in Transactions (sm)"
> > SquareTrade
>
> --Victor Langelo
>
===========================================================================
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".
