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 5738F7781 for ; Fri, 5 Aug 2011 22:07:38 +0000 (UTC) Received: (qmail 12922 invoked by uid 500); 5 Aug 2011 22:07:37 -0000 Delivered-To: apmail-db-derby-user-archive@db.apache.org Received: (qmail 12838 invoked by uid 500); 5 Aug 2011 22:07:37 -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 12826 invoked by uid 99); 5 Aug 2011 22:07:37 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 05 Aug 2011 22:07:37 +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 (nike.apache.org: local policy) Received: from [216.82.241.99] (HELO mail51.messagelabs.com) (216.82.241.99) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 05 Aug 2011 22:07:29 +0000 X-VirusChecked: Checked X-Env-Sender: PBortnovskiy@Jefferies.com X-Msg-Ref: server-12.tower-51.messagelabs.com!1312582028!99232216!1 X-StarScan-Version: 6.2.17; banners=-,-,- X-Originating-IP: [169.196.176.23] Received: (qmail 17148 invoked from network); 5 Aug 2011 22:07:08 -0000 Received: from jefsmtp11.jefferies.com (HELO JEFSMTP11.dmz.jefco.local) (169.196.176.23) by server-12.tower-51.messagelabs.com with RC4-SHA encrypted SMTP; 5 Aug 2011 22:07:08 -0000 In-Reply-To: References: To: "Derby Discussion" MIME-Version: 1.0 Subject: Re: Table exists in same JVM after Derby is shutdown X-KeepSent: D4AE8244:B3D28745-852578E3:0079026E; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.5.2 August 10, 2010 From: Pavel Bortnovskiy Message-ID: Date: Fri, 5 Aug 2011 18:05:42 -0400 X-MIMETrack: Serialize by Router on JefSMTP11/JEFCO(Release 8.5.2FP2|March 22, 2011) at 08/05/2011 06:07:08 PM, Serialize complete at 08/05/2011 06:07:08 PM Content-Type: multipart/alternative; boundary="=_alternative 0079605A852578E3_=" X-Virus-Checked: Checked by ClamAV on apache.org This is a multipart message in MIME format. --=_alternative 0079605A852578E3_= Content-Type: text/plain; charset="US-ASCII" Dag: thank you for your prompt response. The database is entirely in the memory, so there are no files do delete. However, the behavior is consistent and my attached example clearly demonstrates it (has the attachment come through?): 1) I create an in-memory database and then a table in it. Then the database is shut down. 2) The second test tries to create an in-memory db with the same name, and the tables still remain in it, despite that it was explicitly shutdown in the previous test. I would expect that the shutdown effectively cleans everything up. Is it not so? Thanks, Pavel. From: dag.wanvik@oracle.com (Dag H. Wanvik) To: "Derby Discussion" Date: 08/05/2011 05:57 PM Subject: Re: Table exists in same JVM after Derby is shutdown Pavel Bortnovskiy writes: > Hello, all: > > While executing a bunch of JUnit tests within the same JVM (all executed > by IntelliJ IDEA) I started seeing strange and unexpected errors occurring > . > Upon closer inspection, I noticed that in many of those tests tables with > the same names are attempted to be created. > Then I realized that although Derby is shutdown and then re-created, the > tables remain, thus causing collisions. The "create=true" connection attribute is ignored (with a warning) if the database with the same name alrady exists. > > I've created a digest (attached) which is executed as one JUnit test to > illustrate what I'm seeing. > The behavior I would expect is that once Derby is shutdown, no tables > would remain in the JVM, and if a database (with the same name) is > re-created, it would be a tabula rasa. The tables are no longer in memory (or should not be unless you found a bug), but they are not erased from the disk image of the database. As per the above, one would need to explicitly delete it using OS file system tools for the data to be cleared. Some JUnit tests delete tables in TestCase#tearDown, others use singleUseDatabaseDecorator to isolate itself from the rest of the tests. The tests not necessarily very consistent in their patterns for this.. Dag > > Can you please let me know whether my expectations are erroneous and > whether I should find workarounds (albeit trivial to implement). > However, what would concern me in that case is that the tables and the > data remain in the JVM, thus consuming memory > (and, if unused, creating memory leaks). > > Thank you, > > 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 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 request of regulators or > in connection with civil litigation. Jefferies accepts no 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 International Limited; > registered in England: no. 1978621; registered office: Vintners Place, > 68 Upper Thames Street, London EC4V 3BJ. Jefferies International > Limited is authorised and regulated by the Financial Services > Authority. 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 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 request of regulators or in connection with civil litigation. Jefferies accepts no 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 International Limited; registered in England: no. 1978621; registered office: Vintners Place, 68 Upper Thames Street, London EC4V 3BJ. Jefferies International Limited is authorised and regulated by the Financial Services Authority. --=_alternative 0079605A852578E3_= Content-Type: text/html; charset="US-ASCII" Dag: thank you for your prompt response.

The database is entirely in the memory, so there are no files do delete.

However, the behavior is consistent and my attached example clearly demonstrates it (has the attachment come through?):

1) I create an in-memory database and then a table in it.
Then the database is shut down.

2) The second test tries to create an in-memory db with the same name,
and the tables still remain in it, despite that it was explicitly shutdown in the previous test.
I would expect that the shutdown effectively cleans everything up.
Is it not so?

Thanks,
Pavel.


From: dag.wanvik@oracle.com (Dag H. Wanvik)
To: "Derby Discussion" <derby-user@db.apache.org>
Date: 08/05/2011 05:57 PM
Subject: Re: Table exists in same JVM after Derby is shutdown




Pavel Bortnovskiy <PBortnovskiy@Jefferies.com> writes:

> Hello, all:
>
> While executing a bunch of JUnit tests within the same JVM (all executed
> by IntelliJ IDEA) I started seeing strange and unexpected errors occurring
> .
> Upon closer inspection, I noticed that in many of those tests tables with
> the same names are attempted to be created.
> Then I realized that although Derby is shutdown and then re-created, the
> tables remain, thus causing collisions.

The "create=true" connection attribute is ignored (with a warning) if
the database with the same name alrady exists.

>
> I've created a digest (attached) which is executed as one JUnit test to
> illustrate what I'm seeing.
> The behavior I would expect is that once Derby is shutdown, no tables
> would remain in the JVM, and if a database (with the same name) is
> re-created, it would be a tabula rasa.

The tables are no longer in memory (or should not be unless you found a
bug), but they are not erased from the disk image of the database.  As
per the above, one would need to explicitly delete it using OS file
system tools for the data to be cleared. Some JUnit tests delete tables
in TestCase#tearDown, others use singleUseDatabaseDecorator to isolate
itself from the rest of the tests. The tests not necessarily very
consistent in their patterns for this..

Dag

>
> Can you please let me know whether my expectations are erroneous and
> whether I should find workarounds (albeit trivial to implement).
> However, what would concern me in that case is that the tables and the
> data remain in the JVM, thus consuming memory
> (and, if unused, creating memory leaks).
>
> Thank you,
>
> 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 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 request of regulators or
> in connection with civil litigation. Jefferies accepts no 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 International Limited;
> registered in England: no. 1978621; registered office: Vintners Place,
> 68 Upper Thames Street, London EC4V 3BJ.  Jefferies International
> Limited is authorised and regulated by the Financial Services
> Authority.




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 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 request of regulators or in connection with civil litigation. Jefferies accepts no 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 International Limited; registered in England: no. 1978621; registered office: Vintners Place, 68 Upper Thames Street, London EC4V 3BJ. Jefferies International Limited is authorised and regulated by the Financial Services Authority. --=_alternative 0079605A852578E3_=--