Hi Paul, I've never seen a transaction timeout actually cause locks to be released ahead of time before the transaction finally attempts to commit, are you saying that happens? In my experience if you have a 60 second timeout but your transaction doesn't try to commit for 15 minutes then the locks will be held for the full 15 minutes (before finally rolling back when you attempt to commit).
But no sooner did I ask this question about the relevance of timeouts than I came across a good use case for them. If your transaction is wrapping an API call and the intermediate gateways (like a proxy server or whatever) have a timeout, then it can be better to have the transaction timeout shorter than the gateway timeout. In this manner the client won't encounter situations where they receive a gateway timeout error response but the API call they made is actually successful on the server. Regards Scott On Thu, 26 Sep 2019 at 00:46, Paul Foxworthy <[email protected]> wrote: > On Tue, 17 Sep 2019 at 18:45, Scott Gray <[email protected]> > wrote: > > > Has anyone ever had a good experience with transaction timeouts? I feel > > like they achieve nothing useful in that: > > 1. They don't interrupt any work that is taking too long (they just > prevent > > it from being committed) > > 2. By the time the exception is thrown, all the work is already done and > > the result is that it just gets thrown away in exchange for an error > > > > Surely there's a positive side to them, and I've just never seen it? > > > > Hi Scott, > > Timeouts are not good for the transaction, they're good for competing > transactions. > > In many DBMSes, a transaction keeps things locked until commit, to > achieve isolation, the I in ACID. If an unusual error situation arises, or > somebody has designed a transaction (badly) to include a user's think time, > it's possible the transaction does not commit at all, blocking access to > data touched by the transaction for everyone else, indefinitely. > > A transaction timeout is an estimate of a reasonable amount of time within > which the transaction should complete. If it doesn't complete, the timeout > ensures it will roll back, so other transactions won't have to wait too > long. It's something like an operating system segfaulting a rogue process > in order to protect all the others. > > Cheers > > Paul Foxworthy > > -- > Coherent Software Australia Pty Ltd > PO Box 2773 > Cheltenham Vic 3192 > Australia > > Phone: +61 3 9585 6788 > Web: http://www.coherentsoftware.com.au/ > Email: [email protected] >
