db-derby-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rick Hillegas <rick.hille...@oracle.com>
Subject Re: Is it expected that each class loader context gets its own in memory database
Date Mon, 22 Oct 2012 15:50:33 GMT
Hi Kathey,

Here is my $0.02:

On 10/22/12 6:44 AM, Katherine Marsden wrote:
> Creating an in memory database in in different class loader contexts, 
> for example "memory:testdb" seems to create two distinct databases.  
> Is this expected behavior?
If an in-memory database were shared by all class loaders, then you 
could get into the situation of two Derby engines trying to access the 
same in-memory database. I don't think that we have  implemented any 
lock to prevent multiple engines from writing to a shared in-memory 
database. So it makes sense to me that the in-memory database should be 
private to the Derby engine which created it and therefore private to 
the class loader which loaded that engine. And that would lead me to 
expect that each engine (and therefore class loader) would get its own, 
separate namespace of in-memory databases.

In general we don't allow more than one engine to access the same 
database. For that reason, I don't see much value in changing Derby so 
that the namespace of in-memory databases is shared across all engines.

> If so, once the class loader is de-referenced. should it get garbage 
> collected in some way?
A database does not disappear when you shutdown the engine which is 
accessing it. This is true regardless of whether the database is on-disk 
or in-memory. In order to free up the memory consumed by an in-memory 
database, you need to use the "drop=true" attribute on the shutdown url.

Hope these musings are useful,
-Rick
>
>
> Thanks
>
> Kathey
>
> I have some code that shows the behavior but need to get authorization 
> to post it, but just wanted to check whether this is expected.
>
>


Mime
View raw message