This is excellent. I’m looking forward to seeing such exceptions. My use case is not that I insist on using multiple VMs :-o but that we’re doing development, testing, and demonstration on many hosts in a cluster. We’re not always careful about how the installation is configured, so it’s not uncommon for us to sometimes place a TDB instance in the distributed filesystem and have more than one server start up pointing at that location. I’m hoping that this will be prevented.
Now I’ll have more of a clue as to how corruption happens (and possibly prevent most cases). Thanks, Mark On Jul 24, 2014, at 9:58 AM, Rob Vesse <[email protected]> wrote: > Hi All > > In the last couple of days we've enabled a new feature in the TDB code base > that aims to prevent one of the most common causes of data corruption we see > reported on our mailing lists. > > TDB is designed such that only a single JVM can access the database at any > one time which is why we recommend usage of Fuseki if people need to share a > database between applications. However despite clear warnings about this in > the documentation we still see users ignoring this advice and corrupting > their TDB databases as a result. > > The new feature added to the code base should now prevent users from doing > this under most circumstances and throws appropriate exceptions informing > the users that multi-JVM usage has been prevented in order to protect the > database against possible corruption. > > This new functionality is enabled by default and is passing all our unit > tests that use TDB so we are fairly confident in its stability but we would > appreciate anyone who uses TDB who is able to test the latest SNAPSHOTs > please do so in case we have broken any legitimate usages of TDB (This > feature by design breaks some unsafe usages of TDB) > > Thanks, > > Rob > >
