Mailing-List: contact derby-user-help@db.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Derby Discussion" <derby-user@db.apache.org>
Received-SPF: neutral (athena.apache.org: local policy)
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=
  ;
Message-ID: <5073014D.6090307@sbcglobal.net>
Date: Mon, 08 Oct 2012 09:37:33 -0700
From: Katherine Marsden <kmarsdenderby@sbcglobal.net>
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 <derby-user@db.apache.org>
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"

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) 
> <http://old.nabble.com/LOCK_TABLE-not-cleared-%28Derby-10.5%29-tp34515902p34515902.html>
> Sent from the Apache Derby Users mailing list archive 
> <http://old.nabble.com/Apache-Derby-Users-f93.html> at Nabble.com.


--------------050105030601050504020804
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

<html>
  <head>
    <meta content="text/html; charset=ISO-8859-1"
      http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    <div class="moz-cite-prefix">On 10/4/2012 3:29 PM, markvarvil wrote:<br>
    </div>
    <blockquote cite="mid:34515902.post@talk.nabble.com" type="cite">
      Using Derby <b>10.5</b>, and running in <b>network server mode</b>,
      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)?&nbsp;
      <br>
    </blockquote>
    <br>
    Hi Mark,<br>
    <br>
    Likely there are transactions that have not been committed or rolled
    back that are holding these locks.<br>
    The lock timeout&nbsp; is a setting that will determine how long a new
    transaction will wait for existing&nbsp; locks to be released before&nbsp; the
    new transaction times&nbsp; out&nbsp; 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.<br>
    <br>
    One thing to do is to make sure that all transactions are committed
    and rolled back, especially in exception <br>
    circumstances.&nbsp; 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&nbsp; is caught and ignored.&nbsp;&nbsp; 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.<br>
    <br>
    <br>
    Best<br>
    <br>
    Kathey<br>
    &nbsp;<br>
    <br>
    <br>
    <blockquote cite="mid:34515902.post@talk.nabble.com" type="cite">
      <hr align="left" width="300">
      View this message in context: <a moz-do-not-send="true"
href="http://old.nabble.com/LOCK_TABLE-not-cleared-%28Derby-10.5%29-tp34515902p34515902.html">LOCK_TABLE
        not cleared (Derby 10.5)</a><br>
      Sent from the <a moz-do-not-send="true"
        href="http://old.nabble.com/Apache-Derby-Users-f93.html">Apache
        Derby Users mailing list archive</a> at Nabble.com.<br>
    </blockquote>
    <br>
  </body>
</html>

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