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 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 > >
