It is my suspicion that any DB-tier OCC would be *way* faster and more
efficient that an app-server OCC check. Not only it is done natively, but
with all kinds of low-level, same-tier optimizations that an OO app
achitect like me can only imagine. So the question becomes whether the OCC
provided by the DB is what you want.
Tom, I agree with your assessment of the "looseness" of Oracle's
SERIALIZABLE implementation. I would have preferred that they called this
implementation something else, like ROW-SERIALIZABLE or something, and then
provided the fully restrictive implementation as SERIALIZABLE. This would also allow
for no vendor lock-in if you just wanted the full SERIALIZABLE.
This exact characteristic of Oracle is mentioned in an actually pretty
useful book I remember reading a while back. I don't have it in front of
me but I think it is Advanced Java 2 Development for Enterprise
Applications, Second Edition by Clifford J. Berg, mostly boring, but good
chapters on TXs and concurrency.
Anyway, as I am sure you can, I can come up with examples (not many) where
I want to treat more than one row as an atomically changed entity, and I
will not always actually update both rows. In this case I can still get
data integrity violated, not with "stomping" at the row level, but with two
different changes to two different rows that are incompatible.
However, I can't off the top of my head think of a place in my application
where that would occur... so for me, Oracle-SERIALIZABLE, if we can call it
that, might actually be the best thing!
Anybody, are other RDBMS's implementations of Serializable the fully
restrictive version? Do they all support that isolation level?
- Lawrence Bruhmuller
On Wed, 11 Jul 2001 14:59:40 -0400, Larson, Tom <[EMAIL PROTECTED]> wrote:
<other comments snipped>
>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".
>
===========================================================================
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".
