From derby-user-return-14372-apmail-db-derby-user-archive=db.apache.org@db.apache.org Fri Jun 1 19:16:44 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 777699A64 for ; Fri, 1 Jun 2012 19:16:44 +0000 (UTC) Received: (qmail 62361 invoked by uid 500); 1 Jun 2012 19:16:44 -0000 Delivered-To: apmail-db-derby-user-archive@db.apache.org Received: (qmail 62329 invoked by uid 500); 1 Jun 2012 19:16:44 -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 62320 invoked by uid 99); 1 Jun 2012 19:16:44 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 01 Jun 2012 19:16:44 +0000 X-ASF-Spam-Status: No, hits=-0.1 required=5.0 tests=HTML_MESSAGE,RCVD_IN_DNSWL_MED,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: local policy) Received: from [216.82.241.83] (HELO mail37.messagelabs.com) (216.82.241.83) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 01 Jun 2012 19:16:36 +0000 X-Env-Sender: pbortnovskiy@jefferies.com X-Msg-Ref: server-12.tower-37.messagelabs.com!1338578173!20825381!1 X-Originating-IP: [169.196.176.54] X-StarScan-Version: 6.5.10; banners=-,-,- X-VirusChecked: Checked Received: (qmail 14823 invoked from network); 1 Jun 2012 19:16:13 -0000 Received: from mail1.jefferies.com (HELO mail1.jefferies.com) (169.196.176.54) by server-12.tower-37.messagelabs.com with AES128-SHA encrypted SMTP; 1 Jun 2012 19:16:13 -0000 Received: from EXJSQUSDAG01.ad.jefco.com (10.162.114.41) by EXJSQEDGE02.dmz.jefco.local (10.162.35.68) with Microsoft SMTP Server (TLS) id 14.1.355.2; Fri, 1 Jun 2012 15:16:13 -0400 Received: from EXJSQUSDAG04.ad.jefco.com ([169.254.4.187]) by EXJSQUSDAG01.ad.jefco.com ([169.254.1.24]) with mapi id 14.01.0355.002; Fri, 1 Jun 2012 15:16:12 -0400 From: Pavel Bortnovskiy To: "Derby Discussion (derby-user@db.apache.org)" Subject: Derby Locks - best practices Thread-Topic: Derby Locks - best practices Thread-Index: Ac1AKTvEuWxksHZ6SK6keGIJdT2wvw== Date: Fri, 1 Jun 2012 19:16:12 +0000 Message-ID: <619F13B2042F204E8E8E93D73870255809D07231@EXJSQUSDAG04.ad.jefco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.162.93.34] Content-Type: multipart/alternative; boundary="_000_619F13B2042F204E8E8E93D73870255809D07231EXJSQUSDAG04adj_" MIME-Version: 1.0 X-Virus-Checked: Checked by ClamAV on apache.org --_000_619F13B2042F204E8E8E93D73870255809D07231EXJSQUSDAG04adj_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello, all: Derby is used in my application in the in-memory only mode. For a long time= Derby's lock logic caused no worries, but recently some use cases failed w= ith lock timeouts. Thus I'm looking for guidance on best practices for hand= ling locks in Derby. A use-case which may cause timeouts to obtain a lock: = one thread is executing an SQL statement which accesses two (or more) in-me= mory tables. Those two tables are being modified by other threads at rando= m times. So, situations in which the SQL is executed for a long time and th= e other threads are frequently updating the tables may cause lock timeouts. Besides best practices to avoid timeouts and deadlocks, I would like to ask= the following questions: 1) What's the default length of lock timeouts? 2) Does my app need another layer of synchronization mechanism/locks t= o avoid attempts to update in-memory tables or execute SQLs against them? 3) Can my application utilize Derby's locks through some API - to quer= y their state or to use them in making a decision of whether to batch updat= es or to execute them, to wait or execute the SQLs? Your help would be greatly appreciated, Pavel. Jefferies archives and monitors outgoing and incoming e-mail. The contents = of this email, including any attachments, are confidential to the ordinary = user of the email address to which it was addressed. If you are not the add= ressee of this email you may not copy, forward, disclose or otherwise use i= t or any part of it in any form whatsoever. This email may be produced at t= he request of regulators or in connection with civil litigation. Jefferies = accepts no liability for any errors or omissions arising as a result of tra= nsmission. Use by other than intended recipients is prohibited. In the Unit= ed Kingdom, Jefferies operates as Jefferies International Limited; register= ed in England: no. 1978621; registered office: Vintners Place, 68 Upper Tha= mes Street, London EC4V 3BJ. Jefferies International Limited is authorised = and regulated by the Financial Services Authority. --_000_619F13B2042F204E8E8E93D73870255809D07231EXJSQUSDAG04adj_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hello, all:

 

Derby is used in my application in the in-memory onl= y mode. For a long time Derby’s lock logic caused no worries, but rec= ently some use cases failed with lock timeouts. Thus I’m looking for = guidance on best practices for handling locks in Derby. A use-case which may cause timeouts to obtain a lock: one thread= is executing an SQL statement which accesses two (or more) in-memory table= s. Those two tables are being modified by  other threads at random tim= es. So, situations in which the SQL is executed for a long time and the other threads are frequently updating the= tables may cause lock timeouts.

 

Besides best practices to avoid timeouts and deadloc= ks, I would like to ask the following questions:

1)   = ;   What’s the default length of lock timeouts?

2)   = ;   Does my app need another layer of synchronization mechanism/l= ocks to avoid attempts to update in-memory tables or execute SQLs against t= hem?

3)   = ;   Can my application utilize Derby’s locks through some A= PI – to query their state or to use them in making a decision of whet= her to batch updates or to execute them, to wait or execute the SQLs?

 

Your help would be greatly appreciated,

 

Pavel.

Jefferies archives and monitors outgoing and incom= ing e-mail. The contents of this email, including any attachments, are conf= idential to the ordinary user of the email address to which it was addresse= d. If you are not the addressee of this email you may not copy, forward, disclose or otherwise use it or any = part of it in any form whatsoever. This email may be produced at the reques= t of regulators or in connection with civil litigation. Jefferies accepts n= o liability for any errors or omissions arising as a result of transmission. Use by other than intended recipients= is prohibited. In the United Kingdom, Jefferies operates as Jefferies Inte= rnational Limited; registered in England: no. 1978621; registered office: V= intners Place, 68 Upper Thames Street, London EC4V 3BJ. Jefferies International Limited is authorised and regulat= ed by the Financial Services Authority.
--_000_619F13B2042F204E8E8E93D73870255809D07231EXJSQUSDAG04adj_--