Sorry to be a late comer to a painfully long thread, but I just couldn't
help jumping in.
Jonathan K. Weedon wrote:
[lots removed]
3) If you want to avoid "stomping" updates in Oracle, this means using the
serializable isolation level, instead of the default isolation level. This
comes
with some performance overhead, which has yet to be quantified.
[huge amount of stuff deleted]
</jonathan>
I'd like to challenge the assumption about the overhead of Oracle's
implementation.
Here's what Oracle has to say about how they manage OCC in the database
using in a SERIALIZABLE transaction:
<oracle 8i Server Concepts>
To make this determination efficiently, Oracle uses control information
stored in the data block that indicates which rows in the block contain
committed and uncommitted changes. In a sense, the block contains a recent
history of transactions that affected each row in the block. The amount of
history that is retained is controlled by the INITRANS parameter of CREATE
TABLE and ALTER TABLE.
</oracle 8i Server Concepts>
(clipped from
http://otn.oracle.com/docs/products/oracle8i/doc_library/817_doc/server.817/
a76965/c23cnsis.htm#6321)
The data block they are referring to is the same data block that will have
to be interrogated to determine if the version number is stale using app
server OCC. It seems to me that the Oracle approach should provide BETTER
not poorer scalability in that there would be no need for storing, updating,
or interrogating the version number (timestamp, or whatever). It seems to
me that checking the current transaction number against the last committed
transaction number for the row is no more expensive than the app server
implemented check. And regardless of whether the
last-updated-by-transaction-number is used or not, it still is stored and
maintained by Oracle. We might as well take advantage of it.
I've also seen a number of references to the additional workload required to
deal with the exception. I'm a bit confused on this one too. It is true
that the exception must be handled. But that handling will be the same as
the handling of the app server OCC commit failure. There can't be an
automated solution -- regardless of who's doing the OCC. Why?
Take the salary + 1000 update scenario from earlier in this thread. The
only way to reasonably achieve automated recovery would be to maintain a
undo/redo stack of entity bean method calls (including arguments) and
re-apply them all. More naive solutions, would simply reapply the same
value from the failed update and succeed in the very mistake the exception
was designed to prevent.
The entity-bean-method-replay approach might actually work, if we were all
well-behaved entity designers and did all of our validation logic where it
belongs -- in the entity bean. Still, we'd have to deal with the scenario
where the second attempt to increment the salary violated a salary-cap
business constraint. There's no free lunch for us bean developers. Maybe
we'll see something like this someday, but it clearly represents a huge leap
for our app server vendors.
**************************************************************************
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".
