Answers to Carl's questions...
> if a tx represents an attempt to acquire some unique
> resource it makes sense to retry after a "don't know" but
> not after a "really failed" (because you know it will just
> fail again). Not sure why this necessitates changing
> isolation level - why not just retry at the same
> isolation level?
The reason for the "don't know" condition is that the detail
required to assure serialization has been lost due to lack
of space on the interested transaction list. It will not
reappear. Therefore, a retry will yield the same result --
unless you rollback the entire transaction and reissue it.
This would be a reasonable approach -- in fact, it's likely
that same one that would be used in the true "cannot serialize"
case. In both cases, you'd want to requery everything, to
make sure your transaction was starting from an accurate
view of the database.
> Isn't this the same as saying, "don't use Serializable if you
> expect to get a lot of update collisions (i.e. your tx isn't
> really very serializable)"?
Well sort of. Proponents of all the various concurrency
solutions say the same thing -- it can be paraphrased as:
"this may not scale very well if there are lots of collisions".
> Which brings us back to the question, what do you use when
> the nature of the application is such that collisions are
> not exceptional?
Well, we're kind of back to where we started. There's a cost
associated with checking for, failing, and recovering from
collisions. I suspect that we'd agree that pessimistic
locking isn't (generally) the answer. So we must make
assessments as to which OCC solution best fits the environment.
My point in jumping into this thread (a decision I'm beginning
to regret) was to point out that the Oracle RDBMS implementation
of OCC seems to compare favorably with app server or hand coded
OCC solutions. Is right for all cases? Maybe not. It is,
however, a relatively straightforward approach and should be
considered.
> I don't believe that you can always design away these
> conditions...
Granted.
> It used to be the case that MAXTRANS was determined by the
> size of the data block and the DBA is not supposed to
> override it - did that change?
Nope. That's still the default advice.
> In any case, the setting of INITTRANS and MAXTRANS takes
> away from the data block, so it has to be done with care.
Agreed. INITRANS does use space. MAXTRANS allows for it to
be used if needed.
> MAXTRANS is also capped at 255 regardless of block size.
Actually, the practical limit is a bit less than 255. Your
point is well taken though. That is, there is a finite
limit. If the number of concurrent transactions interested
in rows in a single block exceeds that limit, you're in the
"don't know" scenario. Also, I believe there is (or was) a
bug that caused false "don't knows" when INITRANS was set to
one. If folks are seeing the 8177 error in cases where it
"shouldn't" be happening, try changing INITRANS to 2.
> Even if you can get a sufficiently high MAXTRANS,
> "virtually impossible" <> "impossible", and you still
> have to decide how you are going to deal with it when it
> happens.
Agreed.
> Incidentally, the same Concepts manual cited above also
> advises against using Serializable in high-collision
> scenarios because of the costs of rollback.
Sensible advice. However, application managed OCC will
involve rollbacks as well -- they just won't be initiated
by the database itself.
**************************************************************************
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".
