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 51933C594 for ; Fri, 10 Aug 2012 16:32:49 +0000 (UTC) Received: (qmail 5463 invoked by uid 500); 10 Aug 2012 16:32:48 -0000 Delivered-To: apmail-db-derby-user-archive@db.apache.org Received: (qmail 5346 invoked by uid 500); 10 Aug 2012 16:32:48 -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 5338 invoked by uid 99); 10 Aug 2012 16:32:48 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 10 Aug 2012 16:32:48 +0000 X-ASF-Spam-Status: No, hits=-5.0 required=5.0 tests=FSL_RCVD_USER,RCVD_IN_DNSWL_HI,SPF_PASS,UNPARSEABLE_RELAY X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: domain of dag.wanvik@oracle.com designates 148.87.113.117 as permitted sender) Received: from [148.87.113.117] (HELO rcsinet15.oracle.com) (148.87.113.117) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 10 Aug 2012 16:32:37 +0000 Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238]) by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q7AGWFun027821 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Fri, 10 Aug 2012 16:32:16 GMT Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157]) by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id q7AGWF4B015893 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 10 Aug 2012 16:32:15 GMT Received: from abhmt120.oracle.com (abhmt120.oracle.com [141.146.116.72]) by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id q7AGWEZf019440 for ; Fri, 10 Aug 2012 11:32:14 -0500 Received: from localhost (/188.113.85.108) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 10 Aug 2012 09:32:14 -0700 From: dag.wanvik@oracle.com (Dag H. Wanvik) To: "Derby Discussion" Subject: Re: Non-existent conglomerate exception References: <5020BC25.2000709@gmail.com> <50210611.8070602@gmail.com> <50238D9A.7070703@gmail.com> Date: Fri, 10 Aug 2012 18:32:12 +0200 In-Reply-To: <50238D9A.7070703@gmail.com> (Suat Gonul's message of "Thu, 09 Aug 2012 13:14:50 +0300") Message-ID: User-Agent: Gnus/5.110017 (No Gnus v0.17) Emacs/24.0.96 (usg-unix-v) MIME-Version: 1.0 Content-Type: text/plain X-Source-IP: acsinet22.oracle.com [141.146.126.238] Suat Gonul writes: > After setting the derby.language.statementCacheSize property to 0, I > have not received the exception. Maybe I should use the latest release... Good! "latest release": Yes, good idea. I know there has been fixes in the area of invalidating and recompilng cached prepared statements. If you still see the issue, we'd love to get a repro :) Thanks, Dag > > Best, > Suat > > > On 08/07/2012 05:05 PM, Dag H. Wanvik wrote: >> Suat Gonul writes: >> >>> Thanks for the answer! Yes, I also suspected from such a condition and >>> yes, my application does concurrent changes to the revisionTable. One >>> thread might insert records into the revisionTable while the others >>> query/update it. >> At the outset, only changes to the table's schema or creating/dropping >> indexes on it should affect the prepared statement. Plain inserts, >> deletes and updates should not. >> >>> So, how should I handle this case? Is it possible to invalidate the >>> PreparedStatement explicitly? >> I think you can work around it by setting the size of the >> derby.language.statementCacheSize property to 0. >> >> Then every prepare you do will actually compile the query. Would be >> interestng to see it that removed the issue. >> >> >> Thanks, >> Dag >> >>