Simon,
Which build of the snapshot are you running and are you saying it does
not happen on Linux?
Andy
(not near a Windows machine for a few days)
On 02/06/12 00:58, Simon Helsen wrote:
thanks for the quick response Rob,
yes, this is on windows, but I use direct I/O (deliberately) because of
the known problems with mapped I/O. I have not yet had a chance to
follow-up on the suggestions earlier this month to work around the problem
with mapped I/O on windows.
I think this is an entirely different matter though. It seems to me that
the Journal is open when I don't call StoreConnection.release(), but when
I do this, as I mentioned below, the persisted store is lost, i.e even a
new Java process cannot connect to it again (or rather, it can do this,
but thinks the store is empty). It seems to me that that is the problem,
not that the journal object holds on to its channel without an explicit
close. I actually tried to just close the journal, but then it cannot be
re-opened again within the same Java process.
Simon
From:
Rob Vesse<[email protected]>
To:
"[email protected]"<[email protected]>
Date:
06/01/2012 07:06 PM
Subject:
Re: StoreConnection.release() does not allow to connect again
Hi Simon
Are you running on Windows per chance?
TDB uses memory mapped files for its data and there are some issues around
Windows releasing memory mapped files. I thought this was mostly confined
to the case where you were trying to delete such files but maybe it also
applies in this case?
Someone like Andy/Paolo who is more knowledgeable about the internals of
TDB would be better placed to answer your question.
The details of your environment (like OS) will likely be helpful in
tracking down whether this is a bug or not
Rob
On 6/1/12 3:35 PM, "Simon Helsen"<[email protected]> wrote:
Hi everyone,
before filing a bug, I want to make sure I am not doing something wrong.
I
am running in the following problem.
Until I call StoreConnection.release(location) the TDB code holds a lock
on the file system of the index. I think this is the journal file mostly
because I can separately close a dataset.
However, when I call this and then later try to "reconnect", e.g. by
calling StoreConnection.make(location) or just creating a dataset, it
seems that the persisted data is not accessible anymore. I.e. it seems
that StoreConnection.release is doing more than just releasing the
location. It seems to persist something that makes the data go away.
Note that I am seeing this independent on whether I use transactions or
not (I have 2 versions around to compare the transactional and
non-transactional behavior)
This is troublesome. I need some way to "disconnect" from a TDB store (so
all file handles are released), but such that I can reconnect at a later
time. Am I doing something wrong? Or is this a bug?
thanks
Simon
PS: if it is a bug, it would be a showstopper for our 2.7.1 adoption
