Some additional thoughts and clarifications...plus a potentially dangerous
detail about Oracle's SERIALIZABLE implementation -- all embedded below.
> From: Zetie, Carl
>
> Good arguments for Serializable but... I think the real answer is "it
> depends". If I recall correctly, Serializable* can be more
> "efficient", but
> it can also be less "efficient", depending on your access patterns and
> degree of concurrency.
Quite true. However, I was challenging the notion that database level OCC
(Oracle's in particular) is necessarily less efficient. I agree that
efficiency degrades as collisions increase -- regardless of who's managing
the concurrency.
> The main transactional semantic
> tradeoff is that
> Serializable can give you one of three results returned from
> the dbms when you try to commit:
In practice, it's only two. The "don't know" has the exact same behavior as
the "cannot commit". So, as with app server managed OCC, the programmer has
to deal with a single failure scenario. Also, the "don't know" scenario
results from a database not properly configured to handle the concurrent
load. This is a configuration (tuning) issue, not a normal failure scenario
(IMHO).
>
[this section edited down for brevity]
> - the tx committed
>
> - the tx cannot commit
>
> - "don't know" (too many changes have taken place and the tx
> history no longer goes back far enough to determine if the row has
> changed or not). The programmer is going to have to figure out how
> to deal with this in the
> context of the application.
>
> There are also other resource tradeoffs - IIRC correctly, Serializable
> requires retaining multiple versions of a row (i.e. the
> history) depending
> on how many concurrent users of that row there are, whereas explicit
> verification requires only the most recent committed data to
> check against.
Not exactly. Before images must be maintained to support REPEATABLE READ
and even READ COMMITTED in the case of long running queries. This is the
normal behavior for Oracle -- to ensure read consistency by maintaining
rollback information until all clients requiring the BI for read consistency
has completed its work.
>
> In my experience, Serializable works best when the
> transactions really are
> (at least, most of the time) truly serializable, i.e. you
> don't get (many)
> rejected transactions, and works worst when the length of
> transactions and
> degree of concurrency causes a high number of "don't know" results.
I would say it works "better" in the scenario you're describing (few
collisions). However, my assertion is that it may not be better than app
server managed OCC given the same collision profile. (Again, my comments
are limited to Oracle's implementation)
>
> In general, I think you have to choose the verification technique and
> isolation level that matches the characteristics (both performance and
> business semantics) of the tx in question, and there is no
> "best" answer.
Text book -- and I agree.
Now that I'm done pumping up Oracle SERIALIZABLE implementation, let me
offer a sobering reality -- maybe it's a question. It seems to me from the
various sources I've read, that SERIALIZABLE means that if anything I've
read during my transaction changed since my transaction started, they I
can't make database changes of my own. Is this too restrictive?
Anyway, I've done some testing against Oracle's implementation and found
that it's interpretation is a bit looser. Oracle only blocks me from
changing rows that have themselves changed during duration of my
transaction. If other transactions have modified rows that I've merely READ
but don't wish to modify myself, the exception is not thrown.
This may not seem like a big deal until you consider that individual domain
objects (Sales Orders, for instance) will likely span multiple tables and
rows when stored in RDBs.
Anyone else see a problem here?
[tail of Carl's message snipped too]
**************************************************************************
The Information transmitted herewith is sensitive information intended only
for use to the individual or entity to which it is addressed. If the reader
of this message is not the intended recipient, you are hereby notified that
any review, retransmission, dissemination, distribution, copying or other
use of, or taking of any action in reliance upon, this information is
strictly prohibited. If you have received this communication in error,
please contact the sender and delete the material from your computer.
===========================================================================
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".
