<div dir="ltr">I seem to recall, though I couldn't find references to it now, that this could happen if there is a firewall between the RelStorage using processes/threads and your database.<div><br></div><div>If a long time passes without any activity, this could cause the firewall to forget about the long lived TCP connections that RelStorage keeps, and drop packets silently instead of rejecting them, making the RelStorage end seem hung up.</div>

</div><div class="gmail_extra"><br><br><div class="gmail_quote">On Thu, Jul 17, 2014 at 4:20 PM, Sean Upton <span dir="ltr"><<a href="mailto:sdupton@gmail.com" target="_blank">sdupton@gmail.com</a>></span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Any insights from RelStorage users appreciated on this;<br>
<br>
I have a case where multiple Zope2 instances (each with four threads)<br>
get stuck (most/all threads) waiting on execution of LOCK TABLE<br>
statements (presumably stuck commits) in<br>
relstorage.adapters.locker.PostgreSQLLocker.hold_commit_lock [1].<br>
<br>
Any ideas on what I should be looking for in PostgreSQL and possible<br>
causes in my application?<br>
<br>
<br>
Sean<br>
<br>
<br>
[1] Call stack via SIGUSR1 to an instance: <a href="http://pastie.org/9400704" target="_blank">http://pastie.org/9400704</a><br>
_______________________________________________<br>
For more information about ZODB, see <a href="http://zodb.org/" target="_blank">http://zodb.org/</a><br>
<br>
ZODB-Dev mailing list  -  <a href="mailto:ZODB-Dev@zope.org">ZODB-Dev@zope.org</a><br>
<a href="https://mail.zope.org/mailman/listinfo/zodb-dev" target="_blank">https://mail.zope.org/mailman/listinfo/zodb-dev</a><br>
</blockquote></div><br></div>