From derby-user-return-14665-apmail-db-derby-user-archive=db.apache.org@db.apache.org Mon Oct 8 16:38:12 2012 Return-Path: X-Original-To: apmail-db-derby-user-archive@www.apache.org Delivered-To: apmail-db-derby-user-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id A7FE0DD16 for ; Mon, 8 Oct 2012 16:38:12 +0000 (UTC) Received: (qmail 2916 invoked by uid 500); 8 Oct 2012 16:38:12 -0000 Delivered-To: apmail-db-derby-user-archive@db.apache.org Received: (qmail 2809 invoked by uid 500); 8 Oct 2012 16:38:11 -0000 Mailing-List: contact derby-user-help@db.apache.org; run by ezmlm Precedence: bulk list-help: list-unsubscribe: List-Post: List-Id: Reply-To: "Derby Discussion" Delivered-To: mailing list derby-user@db.apache.org Received: (qmail 2798 invoked by uid 99); 8 Oct 2012 16:38:11 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 08 Oct 2012 16:38:11 +0000 X-ASF-Spam-Status: No, hits=2.9 required=5.0 tests=HTML_MESSAGE,RCVD_IN_DNSWL_NONE,SPF_NEUTRAL X-Spam-Check-By: apache.org Received-SPF: neutral (athena.apache.org: local policy) Received: from [98.139.213.151] (HELO nm7-vm0.bullet.mail.bf1.yahoo.com) (98.139.213.151) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 08 Oct 2012 16:38:04 +0000 Received: from [98.139.212.152] by nm7.bullet.mail.bf1.yahoo.com with NNFMP; 08 Oct 2012 16:37:42 -0000 Received: from [66.94.237.109] by tm9.bullet.mail.bf1.yahoo.com with NNFMP; 08 Oct 2012 16:37:42 -0000 Received: from [127.0.0.1] by omp1014.access.mail.mud.yahoo.com with NNFMP; 08 Oct 2012 16:37:42 -0000 X-Yahoo-Newman-Id: 532545.34727.bm@omp1014.access.mail.mud.yahoo.com Received: (qmail 59822 invoked from network); 8 Oct 2012 16:37:42 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=sbcglobal.net; h=DKIM-Signature:X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:Received:Message-ID:Date:From:User-Agent:MIME-Version:To:Subject:References:In-Reply-To:Content-Type; b=MKI42sE4QIcnpVg2O2DG6xAL1/jvoFOxIPjWauJlvgMp7Ksz8YSIeYcAJmp1zfCPVLrE8EUKHadGrRtdxDq9fREDMB8web1xWoRi2DruhQqv3EkkJiIh9n4HHY/xoc78LA8mkIl0S20H4bD6LmPw9tif+0LoveryAa1Dh1G81ts= ; DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sbcglobal.net; s=s1024; t=1349714262; bh=C9m3HELLoK7DEog6/OKxmlv3/Yyd832dmF6zeV2T5ug=; h=X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:Received:Message-ID:Date:From:User-Agent:MIME-Version:To:Subject:References:In-Reply-To:Content-Type; b=cvKpCGsEGxH9jwXNAwcNTZU7bdJWNtQEMVyM+TnSwLYuO4VZg7LJRbbzGHVUnQ6F7N7VZ+WQ9tLXxxl6efY9l7b1+GrwjI5Hx5+VNiY1F4q4hQq2ZLVnvR3SfeN2wwkFksjft3CYw2bI5EaGKz3pmBJzht5Dne0VigGgPIAQESs= X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: p1hYYcEVM1kfo7s0RCWM7iQKYWKSTN9_wCaLQLnWkUqPuuv psSvIF1OMsjeTczlienK49v08kAhd5XtKb5s3nSsDhs4kbo_p.B6lcGN73IU lBQSknSk2gnUPc0ABRYkdxppuBYHXlmXrQDNIRMFim8fMFoOOacSA8YOXPs6 P46MknXKa9c5x4uHLcgmVGNzNfmfEnqarq20HV3O7lI6t7I71kcyV7P66lZn 4J2bhSwp46eW46sQUBwcdCOG8uVZDzyR9b8VJUJdFemYGw074DYGw7hPiAQv Qpy776K5QsRP7Dws5ElcSf5DKlbNumtgD5ClW8P0uflPIHIjNA9JtY6lFY3X hRJeeVVSP1cLZpqByNCT_BPXelrtmgK.GVLS8ItSgw8zZSjkQW5OcLyjrXXq Ju2M.SZ5.foeDREbCtIoS7feWSNkXbjtw.YHEuK52VjD4S8x1Qr_SEb4iSUU Tdn6DFVfWl6ej1cUEFhWB5DATTXUsuqMweGt1iAz_.RSXfVkrHQoPT2oCf1H e53xKipUEkrCw0MUh06zX.O.k..qpKTvdUccfqOcKItssHvbCoDZIV18ea5O wQHC4t4RyEQiThWBqcVLdNn4CbGBX3aSttWsg8WJ0zjDDxDE5C8otZISUcPf EZtT9rl5Nm6vr_Mgh7Ms6Cnm6PZ9ElSoDjfX_SHt6aZiU0TgA37JGdi6lWMo mdgbWaBEZzXV_24eQuQ4.GsC6DmSEi4Y9sSflqKkWfZ9_LnaIjffyggWcLIP 4pYeyh2o1sP4sKIfdY.Kc.j7fDabEVqZabHO8qlWpIE5CmtxnZPLsRfTlVxM L2toYCdMwg6a92n_eFwAEe64UkkOmD5t7l7UjvXjmsOdhvW7pSyRHspO_eHV sD91hd1CkRSPRFw-- X-Yahoo-SMTP: fBd8VESswBBwVkX.d9lIdXduzED_6kJxUAzIjM21tL._95FbORG0yg-- Received: from [192.168.1.71] (kmarsdenderby@108.231.78.45 with plain) by smtp105.sbc.mail.mud.yahoo.com with SMTP; 08 Oct 2012 09:37:42 -0700 PDT Message-ID: <5073014D.6090307@sbcglobal.net> Date: Mon, 08 Oct 2012 09:37:33 -0700 From: Katherine Marsden User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: Derby Discussion Subject: Re: LOCK_TABLE not cleared (Derby 10.5) References: <34515902.post@talk.nabble.com> In-Reply-To: <34515902.post@talk.nabble.com> Content-Type: multipart/alternative; boundary="------------050105030601050504020804" X-Virus-Checked: Checked by ClamAV on apache.org This is a multi-part message in MIME format. --------------050105030601050504020804 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 10/4/2012 3:29 PM, markvarvil wrote: > Using Derby *10.5*, and running in *network server mode*, we have > encountered an issue where the lock_table contained locks, yet these > locks are not being deleted; Even after the system sat idle overnight, > the locks entries persisted in the lock_table the next morning, and > caused the system to function improperly. We are using the default > values for lock and deadlock timeouts. Our application is using JPA > and Optimistic Locking. What would cause the locks to NOT be cleared > and/or released (even after a lengthy timeout period)? Hi Mark, Likely there are transactions that have not been committed or rolled back that are holding these locks. The lock timeout is a setting that will determine how long a new transaction will wait for existing locks to be released before the new transaction times out itself. It does not affect how long the original transaction will hold the locks which will be until the transaction is committed or rolled back. One thing to do is to make sure that all transactions are committed and rolled back, especially in exception circumstances. A frequent case I have seen when transactions and connections are left open is that transactions are not rolled back before attempting to close a connection. Then the exception that is thrown on close is caught and ignored. A global approach to this particular issue might be to replace Connection.close() calls with a method that always rolls back before closing the connection. Best Kathey > ------------------------------------------------------------------------ > View this message in context: LOCK_TABLE not cleared (Derby 10.5) > > Sent from the Apache Derby Users mailing list archive > at Nabble.com. --------------050105030601050504020804 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
On 10/4/2012 3:29 PM, markvarvil wrote:
Using Derby 10.5, and running in network server mode, we have encountered an issue where the lock_table contained locks, yet these locks are not being deleted; Even after the system sat idle overnight, the locks entries persisted in the lock_table the next morning, and caused the system to function improperly. We are using the default values for lock and deadlock timeouts. Our application is using JPA and Optimistic Locking. What would cause the locks to NOT be cleared and/or released (even after a lengthy timeout period)? 

Hi Mark,

Likely there are transactions that have not been committed or rolled back that are holding these locks.
The lock timeout  is a setting that will determine how long a new transaction will wait for existing  locks to be released before  the new transaction times  out  itself. It does not affect how long the original transaction will hold the locks which will be until the transaction is committed or rolled back.

One thing to do is to make sure that all transactions are committed and rolled back, especially in exception
circumstances.  A frequent case I have seen when transactions and connections are left open is that transactions are not rolled back before attempting to close a connection. Then the exception that is thrown on close  is caught and ignored.   A global approach to this particular issue might be to replace Connection.close() calls with a method that always rolls back before closing the connection.


Best

Kathey
 



View this message in context: LOCK_TABLE not cleared (Derby 10.5)
Sent from the Apache Derby Users mailing list archive at Nabble.com.

--------------050105030601050504020804--