On Thu, Nov 4, 2010 at 10:31 AM, Chris Withers <ch...@simplistix.co.uk> wrote: > On 04/11/2010 13:43, Jim Fulton wrote: >>> I'm curious: >>> >>> - Why is the timeout not logged at ERROR or even CRITICAL? >> >> Because it was considered to be neither. It's also not a server error. > > It is an erroneous condition; a transaction has taken long enough that a > timeout has occurred. Thinking about it, it feels more like a > TimeoutException should be raised, but then would the storage server > clean things up properly? > >>> - Is the "inconsistent state" warning genuine here? >> >> Yes. You don't really know whether the transaction committed or not. >> It's much worse if multiple storages are involved. > > ...which of course, they are ;-) > >>> - If that warning is genuine, is there any way the timeout could not >>> leave the client in an inconsistent state? >> >> Absolutely. > > My wording was poor:
So was my reading. (I missed the "not".) > If that warning is genuine, is there any way the timeout could be made > to not leave the client in an inconsistent state? No. > >> This is why I tend to view transaction timeouts as a last resort and >> set the limit >> much higher, 5 minutes. > > Fair enough. Seems odd to have a feature which you seem to be suggestion > should not be used... Actually, I think it should be used, at least for applications with high availability requirements. For applications like our's (ZC's) it amounts to a "don't be stupid" setting. For some applications, it's better to risk inconsistency than to have your application grind to a halt. I consider it an emergency device though, which is why I'd set it pretty high. To be clear, you never want to time out transactions that aren't already hosed. Jim -- Jim Fulton _______________________________________________ For more information about ZODB, see the ZODB Wiki: http://www.zope.org/Wikis/ZODB/ ZODB-Dev mailing list - ZODB-Dev@zope.org https://mail.zope.org/mailman/listinfo/zodb-dev