A few more details to back up my earlier assertions -- which
I still stand by.
>
> Tom, good comments. I do disagree on one point though:
>
> >
> > 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.
>
> I may be being overly pedantic, but I think that there are
> differences in
> some circumstances. In the "don't know" case (i.e. the
> necessary history has
> been aged out) you might potentially fall back on less
> efficient checks to
> determine an exact answer, e.g. the kind of explicit
> verification discussed
> in other threads. Whether it is worth doing so will depend on
> the exact
> semantics and value of the tx. Also there are circumstances
> in which it is
> worth telling the user to try again after a "don't know" but
> not after a
> "can't commit" - think substitutable resources versus unique
> resources.
All nice in theory.
However, the error reported by Oracle for both cases
is identical -- so...
(a) even if we wanted to inform the user of the
"don't know" case, we could not.
(b) even if there is a practical way to retry using
other means we'd have to do it for all failures --
"really failed" and "don't know". FWIW: I don't
think it's a reasonable approach because it would
necessitate changing the isolation level of the
transaction in mid-stream.
>
> However, I will readily agree that in a GREAT MANY real
> world applications, treating a "don't know" the same as a
> "cannot commit" will give the appropriate application
> behavior. Still, its something that a designer has
> to consider, especially in a scenario of high concurrency
GREAT MANY == ALL, for the reason cited above. There's no
other choice.
> > 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).
>
> Yes... and no :-> Certainly the "don't know" comes from the
> database not being configured to handle the concurrent load,
> but in the real world the concurrent load may be unpredictable
> (or have load spikes that it is inefficient to configure for
> in normal usage).
I'd say it's mostly "Yes". Here's the thinking:
(1) LOAD SPIKES DON'T EQUAL COLLISION SPIKES
It is true that real world (especially web) applications
have usage (load) profiles that are difficult to predict.
However, well-designed applications should be constructed
such that UPDATE COLLISIONS are truly exceptional conditions:
husband and wife accessing account simultaneously from their
respective places, for example.
(2) ALLOWING FOR UNUSUAL COLLISION SPIKES IS SPACE
EFFICIENT
The size of Oracle's interested transaction list -- one
list per data block -- is variable in size ranging from
INITRANS to MAXTRANS. ITL is the resource that, when
depleted, yields the "don't know" result.
I assert that application designers and DBAs can collaborate
to establish a MAXTRANS values that would make "don't know"
results virtually impossible -- without wasting space under
normal (non-spike) conditions.
The additional "head room" required for a larger MAXTRANS
setting is effectively "free" unless the worst case scenario
occurs. Even then, the "wasted" space is limited to the
data blocks where the collision spikes occur. In total,
this additional space would be far less than maintaining a
version number on every single row.
> Either way, dealing with the failure scenario ends up with
> the developer, whose program has to shield the
> user from a completely incomprehensible error message...
On this we agree 100%.
...mounting soapbox...
We cannot trust our application servers and databases to
"do the right thing". To quote Ronald Reagan: "we must
trust but verify". A Yogi Berra quality quote to be sure.
I'd re-phrase it to: "we must verify, then trust". I don't
want to DO the concurrency work, but I must be sure that
it's being done well.
...dismounting soapbox...
-Tom
**************************************************************************
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".
