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