On 10/06/12 11:35, Laurent Pellegrino wrote:
Does StoreConnection.reset() work for you? It clears everything - that's
what the TDB test suite uses :
StoreConnection.reset()+FileOps.clearDirectory but there is only one active
location.
And I have also make expel public. Use at your own risk!
Thanks. Unfortunately, I am coming back to an issue you already
discussed: mmap files "cannot" be removed on Windows.
If you look at the test code, you'll see it creates a new directory for
each test on Windows to avoid this problem.
SystemTDB.isWindows
and
ConfigTest.getTestingDirUnique
String DIR = SystemTDB.isWindows ? ConfigTest.getTestingDirUnique() :
ConfigTest.getTestingDir() ;
This technique might be useful to you generally here - rather than clear
and reuse, just create a fresh directory as the location, and delete
everything after the JVBM has exited.
An another issue I have is due a change between the last release and
the current development version: StoreConnection#getLocation now
performs a checkValid() and thus it seems that it is impossible to do
something like:
StoreConnection.release(this.storeConnection.getLocation())
without getting an exception that says "StoreConnection inValid
(issued before a StoreConnection.release?"
You have released this.storeConnection earlier on.
After a release, the StoreConnection instance is no longer in control of
that location and it is marked in valid. You need to get a new
StoreConnection object.
I could store the Location object before to pass it to the
StoreConnection#make but it duplicates values and it does not work if
I build a StoreConnection through a call to
StoreConnection#createMemUncached because the Location is created
internally. Is there a workaround?
Best not to release a #createMemUncached connection - it's a testing
feature outside the management of the global state, which is what the
statics like release() are doing.
Andy
Laurent
On Sat, Jun 9, 2012 at 11:11 PM, Andy Seaborne<[email protected]> wrote:
On 09/06/12 21:00, Laurent Pellegrino wrote:
Hi Andy,
May I ask why do you want to do this?
Briefly, I have some tests that have to use a persistent TDB instance
and that are ending before to handle all the active transactions
because they are not aware of all the transactions which have been
registered. In that case, TDB files cannot be removed at the end of
the test.
Laurent
Does StoreConnection.reset() work for you? It clears everything - that's
what the TDB test suite uses :
StoreConnection.reset()+FileOps.clearDirectory but there is only one active
location.
And I have also make expel public. Use at your own risk!
Andy
On Sat, Jun 9, 2012 at 5:24 PM, Andy Seaborne<[email protected]> wrote:
On 09/06/12 15:03, Laurent Pellegrino wrote:
Hello,
I have some questions about StoreConnection:
1) There is no public method to force a release. Is there a reason for
not having a public release(Location location, boolean force) method
that calls expel(location, true)?
The "force" mode ignores outstanding transactions - as it releases the
location from the cache, it then be possible to have a new managed
datasets
which believed it was in full control, and an existing transaction on a
different managed datasets which also believed it was in full control.
That
can corrupt the data.
2) A call to release throws an exception if there is still some active
transactions when the operation is handled. Thus, if I want to remove
repository files as soon as the connection is closed I have to
iteratively call StoreConnection.release while it does not throws an
exception. I suggest to add a small feature that offers to register an
action to execute once the connection is released. Then, internally it
is possible to use wait/notify mechanism (through
transactionManager.activeTransactions) to execute the action which
have been registered as soon as no transactions are running and the
store is released. Is there already such a feature or can I propose a
small patch for that?
May I ask why do you want to do this? StoreConnection.release is a low
level operation to be used with a lot of care - as the API operations
says
"(testing only)".. Dropping and reopening is expensive. Can the app
manage
transactions as presumably dropping while something a transaction is
active
indicates some implicit constraint is not being adhered to.
Please do suggest a patch - a blocking call to closedown might be better.
If there is a way to releasing when clean after are new transactions
going
to be blocked? And just waiting for no transactions asynchronously needs
some care to avoid a concurrency problem of a new txn being requested
immediately after seeing counts go to zero.
The only reason I know of for needing this is the cache management
implications In an ideal world, there would be a single cache layer and
this would not be necessary. Is that what is the requirement here?
Andy
Kind Regards,
Laurent
