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
