Hi Andy, Thanks for the input, there are a lot of interesting pointers in there, I'll look at them over the weekend and let you know!
Met Vriendelijke Groet / With Kind Regards Bart van Leeuwen twitter: @semanticfire tel. +31(0)6-53182997 Netage B.V. http://netage.nl Esdoornstraat 3 3461ER Linschoten The Netherlands From: Andy Seaborne <[email protected]> To: [email protected] Date: 02-05-2020 11:46 Subject: Re: Migrate Web Application from TDB to TDB2 On 01/05/2020 21:08, Bart van Leeuwen wrote: > Hi, > > I'm trying to migrate a web application which uses TDB to use TDB2 > > From everything I have ready it should be pretty straight forward, but > I immediately run into exceptions like: > > java.nio.channels.OverlappingFileLockException I don't know what this is - it may be an environment factor. Is this Docker? Virtual machines? Or are there classloaders around? > org.apache.jena.tdb2.TDBException: dataset closed In TDB1 close() does not have any effect except that it flushes the database if the dataset has never been used transactionally. There is no need to close databases - transactions are better/safer/robust. In fact, it is a bit meaningless with transactions because there are different views of the data fro different threads. > org.apache.jena.dboe.transaction.txn.TransactionException: Currently in > an active transaction This is API use of the dataset (not Fuseki)? TDB1 works non-transactionally until the app first uses it in a transaction. TDB2 requires transactions from the start. Ideally, use Txn to wrap dataset access. Txn both supports nesting of usage (it is not nested tranactions - it uses the existing trasnaction) and the patten means the code can't forget to commit/abort. https://jena.apache.org/documentation/txn/ https://jena.apache.org/documentation/txn/txn.html Sometimes, apps have code usage that doesn't fit this pattern. --- It looks like there is non-transactional use of the dataset at some point. This does not obviously explain java.nio.channels.OverlappingFileLockException but it might be related. Andy > > I've looked at the samples and the minimal tutorials I could find and > couldn't find hints on what could cause this. > > I did a initdebug: Looks OK. > > JenaSystem.init - start > Found: > InitTDB2 [42] > InitRIOT [20] > InitARQ [30] > InitJenaCore [10] > Initialization sequence: > JenaInitLevel0 [0] > InitJenaCore [10] > InitRIOT [20] > InitARQ [30] > InitTDB2 [42] > Init: JenaInitLevel0 > Init: InitJenaCore > JenaCore.init - start > JenaCore.init - finish > Init: InitRIOT > RIOT.init - start > RIOT.init - finish > Init: InitARQ > ARQ.init - start > ARQ.init - finish > Init: InitTDB2 > TDB2.init - start > TDB.init - finish > JenaSystem.init - finish > > Any help appreciated. > > Met Vriendelijke Groet / With Kind Regards > Bart van Leeuwen > > > twitter: @semanticfire > tel. +31(0)6-53182997 > Netage B.V. > http://netage.nl <http://netage.nl/> > Esdoornstraat 3 > 3461ER Linschoten > The Netherlands
