"Henryk Szal" <szal@doctorq.com.pl> writes:
> My typical short transaction run in 3 seconds (on heavy loaded system 30
> sec.). But without 'timeout
> on lock' it can run 60-180 minutes because someone (user or administrator)
> run long transaction.
> Timeout value is negligible. I set one to 10 sec. because if my two (3 sec.)
> transaction are in conflict, then
> both will be executed (second 3 sec. later).
Thanks, but that actually doesn't answer my question.
I asked: ``What are your actual timing constraints?'' By that I mean,
what real world constraints do you need to satisfy? You aren't
putting in a timeout for your health. You are doing it to acheive
some goal. What is that goal?
I gave three sample goals, still below. Is one of them correct? Or
do you have a different one entirely?
Ian
> Ian Lance Taylor wrote in message ...
> >"Henryk Szal" <szal@doctorq.com.pl> writes:
> >
> >> YES, I DO! My transaction can't wait.
> >> If parser on planner is blocked, then i want to abort my transaction.
> >
> >What are your actual timing constraints? Is the constraint ``no
> >database table access may take longer than 10 seconds?'' Or is it
> >``no database transaction may take longer than 10 seconds?'' Or is
> >the constraint ``this operation may not take longer than 10 seconds?''
> >
> >If the first is the actual constraint, then indeed a timeout on table
> >access is appropriate. But that would be a weird constraint. Can you
> >explain further why you need this?
> >
> >If the second is the actual constraint, that also sounds strange; a
> >database transaction is not normally a complete transaction. You
> >usually have to worry about other communication overhead.
> >
> >If the third is the actual constraint, then shouldn't you do the
> >timeout at the operation level, rather than at the database level?
> >What is preventing you from doing that?
---------------------------(end of broadcast)---------------------------
TIP 582: There are two major products that come out of Berkeley: LSD and UNIX.
We don't believe this to be a coincidence. -- Jeremy S. Anderson