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: pass (nike.apache.org: local policy)
From: dag.wanvik@oracle.com (Dag H. Wanvik)
To: "Derby Discussion" <derby-user@db.apache.org>
Subject: Re: Table exists in same JVM after Derby is shutdown
References: 
 <OFFE4CB487.ED8F5CCC-ON852578E3.006C6DA8-852578E3.006FF362@JEFFERIES.COM>
	<x6zkjnjznz.fsf@oracle.com>
	<OFD4AE8244.B3D28745-ON852578E3.0079026E-852578E3.0079605F@JEFFERIES.COM>
Date: Sat, 06 Aug 2011 00:36:06 +0200
In-Reply-To: 
 <OFD4AE8244.B3D28745-ON852578E3.0079026E-852578E3.0079605F@JEFFERIES.COM>
	(Pavel Bortnovskiy's message of "Fri, 5 Aug 2011 18:05:42 -0400")
Message-ID: <x6vcubjxk9.fsf@oracle.com>
User-Agent: Gnus/5.110017 (No Gnus v0.17) Emacs/23.1 (usg-unix-v)
MIME-Version: 1.0
Content-Type: text/plain

Pavel Bortnovskiy <PBortnovskiy@Jefferies.com> writes:

> 1) I create an in-memory database and then a table in it.
> Then the database is shut down.
> I would expect that the shutdown effectively cleans everything up.
> Is it not so?

Ah, I misunderstood you Pavel. Have a look here:

http://wiki.apache.org/db-derby/InMemoryBackEndPrimer

As you can see, you need to provide the "drop=true" connection
attribute to wipe the data.

Thanks,
Dag

>
> 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.