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?


>> 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 Fulton
For more information about ZODB, see the ZODB Wiki:

ZODB-Dev mailing list  -  ZODB-Dev@zope.org

Reply via email to