> 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. 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?" 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? 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 >>> >>> >>> >
