[
https://issues.apache.org/jira/browse/DERBY-4432?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12773006#action_12773006
]
Kristian Waagan commented on DERBY-4432:
----------------------------------------
Forgot to mention that patch 1a changes the behavior slightly. The in-memory
back end will now behave more like the on-disk back end in that you won't be
able to create database "/tmp/a" if you have already created database
"/tmp/a/b" (there may be some exceptions for both back ends when Derby is
instructed to delete the existing service root). The reason is the check for
whether the service root already exists or not.
> Memory leak when attempting to boot non-existing database with the in-memory
> back end
> -------------------------------------------------------------------------------------
>
> Key: DERBY-4432
> URL: https://issues.apache.org/jira/browse/DERBY-4432
> Project: Derby
> Issue Type: Bug
> Components: Store
> Affects Versions: 10.5.3.0, 10.6.0.0
> Environment: In-memory back end and large amount of boot attempts of
> non-existing databases.
> Reporter: Kristian Waagan
> Assignee: Kristian Waagan
> Attachments: derby-4432-1a-mem_leak_fix.diff,
> derby-4432-1a-mem_leak_fix.stat
>
>
> When attempting to boot a non-existing database with the in-memory back end,
> a DataStore is created and referenced by a map. Since the database doesn't
> exist, Derby won't use the DataStore again and it will hang around
> indefinitely in VFMemoryStorageFactory (or until the same database is
> actually created, in which case the data store will be used).
> FYI, storage factory instances are instantiated liberally, including for the
> same service (i.e. six instances of VFMemoryStorageFactory may be created to
> boot "jdbc:derby:memory:myDB").
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
