From jdo-dev-return-8376-apmail-db-jdo-dev-archive=www.apache.org@db.apache.org Mon Nov 16 17:27:56 2009 Return-Path: Delivered-To: apmail-db-jdo-dev-archive@www.apache.org Received: (qmail 2776 invoked from network); 16 Nov 2009 17:27:56 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.3) by minotaur.apache.org with SMTP; 16 Nov 2009 17:27:56 -0000 Received: (qmail 2164 invoked by uid 500); 16 Nov 2009 17:27:56 -0000 Mailing-List: contact jdo-dev-help@db.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: jdo-dev@db.apache.org Delivered-To: mailing list jdo-dev@db.apache.org Received: (qmail 2154 invoked by uid 99); 16 Nov 2009 17:27:55 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 16 Nov 2009 17:27:55 +0000 X-ASF-Spam-Status: No, hits=-4.6 required=5.0 tests=AWL,BAYES_00 X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of joerg.von.frantzius@artnology.com designates 80.67.31.27 as permitted sender) Received: from [80.67.31.27] (HELO smtprelay04.ispgateway.de) (80.67.31.27) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 16 Nov 2009 17:27:53 +0000 Received: from [80.153.219.11] (helo=[192.168.100.26]) by smtprelay04.ispgateway.de with esmtpa (Exim 4.68) (envelope-from ) id 1NA5MR-0006rT-8f; Mon, 16 Nov 2009 18:27:31 +0100 Message-ID: <4B018B82.20603@artnology.com> Date: Mon, 16 Nov 2009 18:27:30 +0100 From: Joerg von Frantzius User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.4pre) Gecko/20090915 SUSE/3.0b4-3.6 Lightning/1.0pre Thunderbird/3.0b4 MIME-Version: 1.0 To: Apache JDO project CC: JDO Expert Group Subject: Update timeout? Content-Type: multipart/mixed; boundary="------------050507060000000703010101" X-Df-Sender: 383542 --------------050507060000000703010101 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Hi, the other day we had the problem that a row lock got held indefinitely in a production database, probably because of the appserver not properly committing a connection. As a consequence, the HTTP-threads of the appserver got blocked one after the other, during execution of an UPDATE statement. This eventually lead to the whole appserver cluster to hang, when all HTTP thread pools were filled with blocked threads. The consequences of a single hanging row-lock could be much less drastic if something like an update timeout existed. I was hoping that http://java.sun.com/j2se/1.4.2/docs/api/java/sql/Statement.html#setQueryTimeout(int) applies to both SELECT and UPDATE statements, so that threads blocked in a UPDATE statement wouldn't do so forever. What do you think of having an additional javax.jdo.option.UpdateTimeout PMF property for this? Currently there is no way for an application to access any java.sql.Statement object used by the JDO implementation to invoke setQueryTimeout() by itself, so in order to have update timeouts with JDO, some extension of the spec would be necessary? Regards, Jörg -- ____________________________________________________________________ artnology GmbH - Milastraße 4 - 10437 Berlin - Germany Geschäftsführer: Ekkehard Blome (CEO), Felix Kuschnick (CCO) Registergericht: Amtsgericht Berlin Charlottenburg HRB 76376 UST-Id. DE 217652550 --------------050507060000000703010101--