You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@jena.apache.org by Kurt Landen <st...@gmail.com> on 2013/08/08 15:59:55 UTC
Models remaining in memory
I am currently using a method I made which just uses Apache FileUtils to
delete the folder containing my TDB, but if I add named models to the
Dataset, the models will still be accessible in memory even after the
physical models are gone. If I called addNamedModel it will tell me the
model already exists when I delete the TDB folder and re-create it. How can
I fix this?
Re: Models remaining in memory
Posted by Andy Seaborne <an...@apache.org>.
On 08/08/13 16:59, Kurt Landen wrote:
> Why do you want to delete the folder?
>
> I want to be able to drop a dataset that I create
>
> What exactly is the dataset you are using?
>
> When the dataset is created, I use TDBFactory.createDataset(), I've just
> been using the Dataset interface.
>
> How would I set up a StoredConnection?
> I realize that this does not work on Windows 64-bit.
I was typing too quicky s/d// . The internal operation is
StoreConnection.release(Location)
it's better to use the public API:
TDBFactory.release(location)
TDB keeps a cache of all databases by location so when you ask for one
you always get the same one, same caches and same transaction manager.
StoreConnection's are that single instance of the attachment to the
database at a location.
Andy
>
>
> On Thu, Aug 8, 2013 at 10:34 AM, Andy Seaborne <an...@apache.org> wrote:
>
>> On 08/08/13 14:59, Kurt Landen wrote:
>>
>>> I am currently using a method I made which just uses Apache FileUtils to
>>> delete the folder containing my TDB, but if I add named models to the
>>> Dataset, the models will still be accessible in memory even after the
>>> physical models are gone. If I called addNamedModel it will tell me the
>>> model already exists when I delete the TDB folder and re-create it. How
>>> can
>>> I fix this?
>>>
>>>
>> Why do you want to delete the folder?
>>
>> What exactly is the dataset you are using?
>>
>> Deleting files behind TDB's back can only be done with great care. You
>> must use StoredConnection.release() to expel it from the in-JVM cache. Then
>> delete the files, then reopen it the database.
>>
>> Otherwise, the caches are still there and some of your data is still
>> around. Eventually something will go wrong. Such data is not persistent.
>>
>> This does not work on Windows/64bit. This is a well-documented issue on
>> MS Windows with memory mapped files.
>>
>> Andy
>>
>>
>
Re: Models remaining in memory
Posted by Kurt Landen <st...@gmail.com>.
Why do you want to delete the folder?
I want to be able to drop a dataset that I create
What exactly is the dataset you are using?
When the dataset is created, I use TDBFactory.createDataset(), I've just
been using the Dataset interface.
How would I set up a StoredConnection?
I realize that this does not work on Windows 64-bit.
On Thu, Aug 8, 2013 at 10:34 AM, Andy Seaborne <an...@apache.org> wrote:
> On 08/08/13 14:59, Kurt Landen wrote:
>
>> I am currently using a method I made which just uses Apache FileUtils to
>> delete the folder containing my TDB, but if I add named models to the
>> Dataset, the models will still be accessible in memory even after the
>> physical models are gone. If I called addNamedModel it will tell me the
>> model already exists when I delete the TDB folder and re-create it. How
>> can
>> I fix this?
>>
>>
> Why do you want to delete the folder?
>
> What exactly is the dataset you are using?
>
> Deleting files behind TDB's back can only be done with great care. You
> must use StoredConnection.release() to expel it from the in-JVM cache. Then
> delete the files, then reopen it the database.
>
> Otherwise, the caches are still there and some of your data is still
> around. Eventually something will go wrong. Such data is not persistent.
>
> This does not work on Windows/64bit. This is a well-documented issue on
> MS Windows with memory mapped files.
>
> Andy
>
>
Re: Models remaining in memory
Posted by Andy Seaborne <an...@apache.org>.
On 08/08/13 16:52, David Jordan wrote:
> Andy, With regard to your statement "This is a well-documented issue
> on MS Windows with memory mapped files (on Windows 64bit)". What are
> all the things that this could affect if one is running TDB on
> Windows 64bit? Is it only the deletion of underlying TDB files? Or
> are there other issues as well? During development I have deleted the
> files of a TDB database. But I did this when I had no software
> running against the TDB database.
Just deleting the database on disk in a running system.
If there are no running instances, it's just files on disk. If they
can't be deleted then you may wish to talk sternly to your OS!
> It is my understanding that my single JVM is the only running process
> against the TDB database, that there is not a separate server
> processing running, which may continue to run after I have terminated
> my application process. Is that true? If one is not currently running
> a JVM using TDB on a particular TDB store, there should not be a
> problem with the deletion of the files, correct?
True. No hidden processes.
If your running TDB in an application, then the database engine is
embedded in the application JVM.
Andy
RE: Models remaining in memory
Posted by David Jordan <Da...@sas.com>.
Andy,
With regard to your statement "This is a well-documented issue on MS Windows with memory mapped files (on Windows 64bit)".
What are all the things that this could affect if one is running TDB on Windows 64bit? Is it only the deletion of underlying TDB files? Or are there other issues as well? During development I have deleted the files of a TDB database. But I did this when I had no software running against the TDB database.
It is my understanding that my single JVM is the only running process against the TDB database, that there is not a separate server processing running, which may continue to run after I have terminated my application process. Is that true? If one is not currently running a JVM using TDB on a particular TDB store, there should not be a problem with the deletion of the files, correct?
-----Original Message-----
From: Andy Seaborne [mailto:andy@apache.org]
Sent: Thursday, August 08, 2013 11:35 AM
To: users@jena.apache.org
Subject: Re: Models remaining in memory
On 08/08/13 14:59, Kurt Landen wrote:
> I am currently using a method I made which just uses Apache FileUtils
> to delete the folder containing my TDB, but if I add named models to
> the Dataset, the models will still be accessible in memory even after
> the physical models are gone. If I called addNamedModel it will tell
> me the model already exists when I delete the TDB folder and re-create
> it. How can I fix this?
>
Why do you want to delete the folder?
What exactly is the dataset you are using?
Deleting files behind TDB's back can only be done with great care. You must use StoredConnection.release() to expel it from the in-JVM cache.
Then delete the files, then reopen it the database.
Otherwise, the caches are still there and some of your data is still around. Eventually something will go wrong. Such data is not persistent.
This does not work on Windows/64bit. This is a well-documented issue on MS Windows with memory mapped files.
Andy
Re: Models remaining in memory
Posted by Andy Seaborne <an...@apache.org>.
On 08/08/13 14:59, Kurt Landen wrote:
> I am currently using a method I made which just uses Apache FileUtils to
> delete the folder containing my TDB, but if I add named models to the
> Dataset, the models will still be accessible in memory even after the
> physical models are gone. If I called addNamedModel it will tell me the
> model already exists when I delete the TDB folder and re-create it. How can
> I fix this?
>
Why do you want to delete the folder?
What exactly is the dataset you are using?
Deleting files behind TDB's back can only be done with great care. You
must use StoredConnection.release() to expel it from the in-JVM cache.
Then delete the files, then reopen it the database.
Otherwise, the caches are still there and some of your data is still
around. Eventually something will go wrong. Such data is not persistent.
This does not work on Windows/64bit. This is a well-documented issue on
MS Windows with memory mapped files.
Andy