On 2017-12-29 11:05, dandh988 wrote:
> Not quite the complete working example I was expecting but...
I'm sorry. It is a rest service and don't have kind of "unit-test". For the
moment I cannot disclose code.
> Can you post the exception stack please?
2017-12-29 10:14:30.101 [default task-58] ERROR
com.myproject.rest.exceptions.UncaughtThrowableExceptionMapper - Uncaught
throwable exception
org.apache.jena.tdb.base.file.FileException: In the middle of an alloc-write
at
org.apache.jena.tdb.base.objectfile.ObjectFileStorage.read(ObjectFileStorage.java:311)
~[jena-tdb-3.5.0.jar:3.5.0]
at
org.apache.jena.tdb.base.objectfile.ObjectFileWrapper.read(ObjectFileWrapper.java:57)
~[jena-tdb-3.5.0.jar:3.5.0]
at org.apache.jena.tdb.lib.NodeLib.fetchDecode(NodeLib.java:78)
~[jena-tdb-3.5.0.jar:3.5.0]
at
org.apache.jena.tdb.store.nodetable.NodeTableNative.readNodeFromTable(NodeTableNative.java:186)
~[jena-tdb-3.5.0.jar:3.5.0]
at
org.apache.jena.tdb.store.nodetable.NodeTableNative._retrieveNodeByNodeId(NodeTableNative.java:111)
~[jena-tdb-3.5.0.jar:3.5.0]
at
org.apache.jena.tdb.store.nodetable.NodeTableNative.getNodeForNodeId(NodeTableNative.java:70)
~[jena-tdb-3.5.0.jar:3.5.0]
at
org.apache.jena.tdb.store.nodetable.NodeTableCache._retrieveNodeByNodeId(NodeTableCache.java:128)
~[jena-tdb-3.5.0.jar:3.5.0]
at
org.apache.jena.tdb.store.nodetable.NodeTableCache.getNodeForNodeId(NodeTableCache.java:82)
~[jena-tdb-3.5.0.jar:3.5.0]
at
org.apache.jena.tdb.store.nodetable.NodeTableWrapper.getNodeForNodeId(NodeTableWrapper.java:50)
~[jena-tdb-3.5.0.jar:3.5.0]
at
org.apache.jena.tdb.store.nodetable.NodeTableInline.getNodeForNodeId(NodeTableInline.java:67)
~[jena-tdb-3.5.0.jar:3.5.0]
at org.apache.jena.tdb.lib.TupleLib.quad(TupleLib.java:129)
~[jena-tdb-3.5.0.jar:3.5.0]
at org.apache.jena.tdb.lib.TupleLib.quad(TupleLib.java:123)
~[jena-tdb-3.5.0.jar:3.5.0]
at
org.apache.jena.tdb.lib.TupleLib.lambda$convertToQuads$3(TupleLib.java:59)
~[jena-tdb-3.5.0.jar:3.5.0]
at org.apache.jena.atlas.iterator.Iter$2.next(Iter.java:270)
~[jena-base-3.5.0.jar:3.5.0]
at org.apache.jena.atlas.iterator.Iter$2.next(Iter.java:270)
~[jena-base-3.5.0.jar:3.5.0]
at org.apache.jena.atlas.iterator.Iter.next(Iter.java:875)
~[jena-base-3.5.0.jar:3.5.0]
at
org.apache.jena.util.iterator.WrappedIterator.next(WrappedIterator.java:94)
~[jena-core-3.5.0.jar:3.5.0]
at
org.apache.jena.util.iterator.WrappedIterator.next(WrappedIterator.java:94)
~[jena-core-3.5.0.jar:3.5.0]
at
org.apache.jena.util.iterator.FilterIterator.hasNext(FilterIterator.java:56)
~[jena-core-3.5.0.jar:3.5.0]
at
org.apache.jena.util.iterator.NiceIterator$1.hasNext(NiceIterator.java:105)
~[jena-core-3.5.0.jar:3.5.0]
at
org.apache.jena.util.iterator.WrappedIterator.hasNext(WrappedIterator.java:90)
~[jena-core-3.5.0.jar:3.5.0]
at
org.apache.jena.sparql.engine.iterator.QueryIterTriplePattern$TripleMapper.hasNextBinding(QueryIterTriplePattern.java:135)
~[jena-arq-3.5.0.jar:3.5.0]
at
org.apache.jena.sparql.engine.iterator.QueryIteratorBase.hasNext(QueryIteratorBase.java:114)
~[jena-arq-3.5.0.jar:3.5.0]
at
org.apache.jena.sparql.engine.iterator.QueryIterRepeatApply.hasNextBinding(QueryIterRepeatApply.java:74)
~[jena-arq-3.5.0.jar:3.5.0]
at
org.apache.jena.sparql.engine.iterator.QueryIteratorBase.hasNext(QueryIteratorBase.java:114)
~[jena-arq-3.5.0.jar:3.5.0]
at
org.apache.jena.sparql.engine.iterator.QueryIterRepeatApply.makeNextStage(QueryIterRepeatApply.java:101)
~[jena-arq-3.5.0.jar:3.5.0]
at
org.apache.jena.sparql.engine.iterator.QueryIterRepeatApply.hasNextBinding(QueryIterRepeatApply.java:65)
~[jena-arq-3.5.0.jar:3.5.0]
at
org.apache.jena.sparql.engine.iterator.QueryIteratorBase.hasNext(QueryIteratorBase.java:114)
~[jena-arq-3.5.0.jar:3.5.0]
at
org.apache.jena.sparql.engine.iterator.QueryIterRepeatApply.makeNextStage(QueryIterRepeatApply.java:101)
~[jena-arq-3.5.0.jar:3.5.0]
at
org.apache.jena.sparql.engine.iterator.QueryIterRepeatApply.hasNextBinding(QueryIterRepeatApply.java:65)
~[jena-arq-3.5.0.jar:3.5.0]
at
org.apache.jena.sparql.engine.iterator.QueryIteratorBase.hasNext(QueryIteratorBase.java:114)
~[jena-arq-3.5.0.jar:3.5.0]
at
org.apache.jena.sparql.engine.iterator.QueryIterRepeatApply.makeNextStage(QueryIterRepeatApply.java:101)
~[jena-arq-3.5.0.jar:3.5.0]
at
org.apache.jena.sparql.engine.iterator.QueryIterRepeatApply.hasNextBinding(QueryIterRepeatApply.java:65)
~[jena-arq-3.5.0.jar:3.5.0]
at
org.apache.jena.sparql.engine.iterator.QueryIteratorBase.hasNext(QueryIteratorBase.java:114)
~[jena-arq-3.5.0.jar:3.5.0]
at
org.apache.jena.sparql.engine.iterator.QueryIterRepeatApply.makeNextStage(QueryIterRepeatApply.java:101)
~[jena-arq-3.5.0.jar:3.5.0]
at
org.apache.jena.sparql.engine.iterator.QueryIterRepeatApply.hasNextBinding(QueryIterRepeatApply.java:65)
~[jena-arq-3.5.0.jar:3.5.0]
at
org.apache.jena.sparql.engine.iterator.QueryIteratorBase.hasNext(QueryIteratorBase.java:114)
~[jena-arq-3.5.0.jar:3.5.0]
at
org.apache.jena.sparql.engine.iterator.QueryIterRepeatApply.makeNextStage(QueryIterRepeatApply.java:101)
~[jena-arq-3.5.0.jar:3.5.0]
at
org.apache.jena.sparql.engine.iterator.QueryIterRepeatApply.hasNextBinding(QueryIterRepeatApply.java:65)
~[jena-arq-3.5.0.jar:3.5.0]
at
org.apache.jena.sparql.engine.iterator.QueryIteratorBase.hasNext(QueryIteratorBase.java:114)
~[jena-arq-3.5.0.jar:3.5.0]
at
org.apache.jena.sparql.engine.iterator.QueryIterBlockTriples.hasNextBinding(QueryIterBlockTriples.java:63)
~[jena-arq-3.5.0.jar:3.5.0]
at
org.apache.jena.sparql.engine.iterator.QueryIteratorBase.hasNext(QueryIteratorBase.java:114)
~[jena-arq-3.5.0.jar:3.5.0]
at
org.apache.jena.sparql.engine.main.StageGeneratorGeneric.execute(StageGeneratorGeneric.java:61)
~[jena-arq-3.5.0.jar:3.5.0]
at
org.apache.jena.sparql.engine.main.StageGeneratorGeneric.execute(StageGeneratorGeneric.java:53)
~[jena-arq-3.5.0.jar:3.5.0]
at
org.apache.jena.tdb.solver.StageGeneratorDirectTDB.execute(StageGeneratorDirectTDB.java:53)
~[jena-tdb-3.5.0.jar:3.5.0]
at
org.apache.jena.tdb2.solver.StageGeneratorDirectTDB.execute(StageGeneratorDirectTDB.java:53)
~[jena-tdb2-3.5.0.jar:3.5.0]
at
org.apache.jena.sparql.engine.main.OpExecutor.execute(OpExecutor.java:128)
~[jena-arq-3.5.0.jar:3.5.0]
at
org.apache.jena.sparql.engine.main.ExecutionDispatch.visit(ExecutionDispatch.java:58)
~[jena-arq-3.5.0.jar:3.5.0]
at org.apache.jena.sparql.algebra.op.OpBGP.visit(OpBGP.java:49)
~[jena-arq-3.5.0.jar:3.5.0]
at
org.apache.jena.sparql.engine.main.ExecutionDispatch.exec(ExecutionDispatch.java:46)
~[jena-arq-3.5.0.jar:3.5.0]
at
org.apache.jena.sparql.engine.main.OpExecutor.exec(OpExecutor.java:117)
~[jena-arq-3.5.0.jar:3.5.0]
at
org.apache.jena.sparql.engine.main.OpExecutor.execute(OpExecutor.java:299)
~[jena-arq-3.5.0.jar:3.5.0]
at
org.apache.jena.sparql.engine.main.ExecutionDispatch.visit(ExecutionDispatch.java:187)
~[jena-arq-3.5.0.jar:3.5.0]
at org.apache.jena.sparql.algebra.op.OpFilter.visit(OpFilter.java:132)
~[jena-arq-3.5.0.jar:3.5.0]
at
org.apache.jena.sparql.engine.main.ExecutionDispatch.exec(ExecutionDispatch.java:46)
~[jena-arq-3.5.0.jar:3.5.0]
at
org.apache.jena.sparql.engine.main.OpExecutor.exec(OpExecutor.java:117)
~[jena-arq-3.5.0.jar:3.5.0]
at
org.apache.jena.sparql.engine.main.OpExecutor.execute(OpExecutor.java:228)
~[jena-arq-3.5.0.jar:3.5.0]
at
org.apache.jena.sparql.engine.main.ExecutionDispatch.visit(ExecutionDispatch.java:130)
~[jena-arq-3.5.0.jar:3.5.0]
at
org.apache.jena.sparql.algebra.op.OpSequence.visit(OpSequence.java:75)
~[jena-arq-3.5.0.jar:3.5.0]
at
org.apache.jena.sparql.engine.main.ExecutionDispatch.exec(ExecutionDispatch.java:46)
~[jena-arq-3.5.0.jar:3.5.0]
at
org.apache.jena.sparql.engine.main.OpExecutor.exec(OpExecutor.java:117)
~[jena-arq-3.5.0.jar:3.5.0]
at
org.apache.jena.sparql.engine.main.OpExecutor.execute(OpExecutor.java:228)
~[jena-arq-3.5.0.jar:3.5.0]
at
org.apache.jena.sparql.engine.main.ExecutionDispatch.visit(ExecutionDispatch.java:130)
~[jena-arq-3.5.0.jar:3.5.0]
at
org.apache.jena.sparql.algebra.op.OpSequence.visit(OpSequence.java:75)
~[jena-arq-3.5.0.jar:3.5.0]
at
org.apache.jena.sparql.engine.main.ExecutionDispatch.exec(ExecutionDispatch.java:46)
~[jena-arq-3.5.0.jar:3.5.0]
at
org.apache.jena.sparql.engine.main.OpExecutor.exec(OpExecutor.java:117)
~[jena-arq-3.5.0.jar:3.5.0]
at
org.apache.jena.sparql.engine.main.OpExecutor.execute(OpExecutor.java:405)
~[jena-arq-3.5.0.jar:3.5.0]
at
org.apache.jena.sparql.engine.main.ExecutionDispatch.visit(ExecutionDispatch.java:315)
~[jena-arq-3.5.0.jar:3.5.0]
at org.apache.jena.sparql.algebra.op.OpGroup.visit(OpGroup.java:54)
~[jena-arq-3.5.0.jar:3.5.0]
at
org.apache.jena.sparql.engine.main.ExecutionDispatch.exec(ExecutionDispatch.java:46)
~[jena-arq-3.5.0.jar:3.5.0]
at
org.apache.jena.sparql.engine.main.OpExecutor.exec(OpExecutor.java:117)
~[jena-arq-3.5.0.jar:3.5.0]
at
org.apache.jena.sparql.engine.main.OpExecutor.execute(OpExecutor.java:376)
~[jena-arq-3.5.0.jar:3.5.0]
at
org.apache.jena.sparql.engine.main.ExecutionDispatch.visit(ExecutionDispatch.java:323)
~[jena-arq-3.5.0.jar:3.5.0]
at org.apache.jena.sparql.algebra.op.OpTopN.visit(OpTopN.java:50)
~[jena-arq-3.5.0.jar:3.5.0]
at
org.apache.jena.sparql.engine.main.ExecutionDispatch.exec(ExecutionDispatch.java:46)
~[jena-arq-3.5.0.jar:3.5.0]
at
org.apache.jena.sparql.engine.main.OpExecutor.exec(OpExecutor.java:117)
~[jena-arq-3.5.0.jar:3.5.0]
at
org.apache.jena.sparql.engine.main.OpExecutor.execute(OpExecutor.java:88)
~[jena-arq-3.5.0.jar:3.5.0]
at org.apache.jena.sparql.engine.main.QC.execute(QC.java:52)
~[jena-arq-3.5.0.jar:3.5.0]
at
org.apache.jena.sparql.engine.main.QueryEngineMain.eval(QueryEngineMain.java:55)
~[jena-arq-3.5.0.jar:3.5.0]
at
org.apache.jena.sparql.engine.QueryEngineBase.evaluate(QueryEngineBase.java:136)
~[jena-arq-3.5.0.jar:3.5.0]
at
org.apache.jena.sparql.engine.QueryEngineBase.createPlan(QueryEngineBase.java:106)
~[jena-arq-3.5.0.jar:3.5.0]
at
org.apache.jena.sparql.engine.QueryEngineBase.getPlan(QueryEngineBase.java:87)
~[jena-arq-3.5.0.jar:3.5.0]
at
org.apache.jena.sparql.engine.main.QueryEngineMain$QueryEngineMainFactory.create(QueryEngineMain.java:90)
~[jena-arq-3.5.0.jar:3.5.0]
at
org.apache.jena.sparql.engine.QueryExecutionBase.getPlan(QueryExecutionBase.java:524)
~[jena-arq-3.5.0.jar:3.5.0]
at
org.apache.jena.sparql.engine.QueryExecutionBase.startQueryIterator(QueryExecutionBase.java:472)
~[jena-arq-3.5.0.jar:3.5.0]
at
org.apache.jena.sparql.engine.QueryExecutionBase.execAsk(QueryExecutionBase.java:331)
~[jena-arq-3.5.0.jar:3.5.0]
at
com.myproject.storage.semantic.tdb.ReadSparqlExecutor.lambda$execute$0(ReadSparqlExecutor.java:67)
~[classes:?]
at org.apache.jena.system.Txn.calculateRead(Txn.java:56)
~[jena-arq-3.5.0.jar:3.5.0]
at
com.myproject.storage.semantic.tdb.ReadSparqlExecutor.execute(ReadSparqlExecutor.java:51)
~[classes:?]
at
com.myproject.rest.QueryRestService.askBeforeExecute(QueryRestService.java:492)
~[classes:?]
at
com.myproject.rest.QueryRestService.executeQueryStream(QueryRestService.java:665)
~[classes:?]
at
com.myproject.rest.QueryRestService.executeQuery(QueryRestService.java:453)
~[classes:?]
at
com.myproject.rest.QueryRestService$Proxy$_$$_WeldClientProxy.executeQuery(Unknown
Source) ~[classes:?]
at sun.reflect.GeneratedMethodAccessor365.invoke(Unknown Source) ~[?:?]
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
~[?:1.8.0_121]
at java.lang.reflect.Method.invoke(Method.java:498) ~[?:1.8.0_121]
at
org.jboss.resteasy.core.MethodInjectorImpl.invoke(MethodInjectorImpl.java:139)
~[resteasy-jaxrs-3.0.14.Final.jar!/:3.0.14.Final]
at
org.jboss.resteasy.core.ResourceMethodInvoker.invokeOnTarget(ResourceMethodInvoker.java:295)
~[resteasy-jaxrs-3.0.14.Final.jar!/:3.0.14.Final]
at
org.jboss.resteasy.core.ResourceMethodInvoker.invoke(ResourceMethodInvoker.java:249)
~[resteasy-jaxrs-3.0.14.Final.jar!/:3.0.14.Final]
at
org.jboss.resteasy.core.ResourceMethodInvoker.invoke(ResourceMethodInvoker.java:236)
~[resteasy-jaxrs-3.0.14.Final.jar!/:3.0.14.Final]
at
org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:395)
[resteasy-jaxrs-3.0.14.Final.jar!/:3.0.14.Final]
at
org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:202)
[resteasy-jaxrs-3.0.14.Final.jar!/:3.0.14.Final]
at
org.jboss.resteasy.plugins.server.servlet.ServletContainerDispatcher.service(ServletContainerDispatcher.java:221)
[resteasy-jaxrs-3.0.14.Final.jar!/:3.0.14.Final]
at
org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:56)
[resteasy-jaxrs-3.0.14.Final.jar!/:3.0.14.Final]
at
org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:51)
[resteasy-jaxrs-3.0.14.Final.jar!/:3.0.14.Final]
at javax.servlet.http.HttpServlet.service(HttpServlet.java:790)
[jboss-servlet-api_3.1_spec-1.0.0.Final.jar!/:1.0.0.Final]
at
io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:85)
[undertow-servlet-1.3.15.Final.jar!/:1.3.15.Final]
at
io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:129)
[undertow-servlet-1.3.15.Final.jar!/:1.3.15.Final]
at
org.apache.logging.log4j.web.Log4jServletFilter.doFilter(Log4jServletFilter.java:71)
[log4j-web-2.5.jar:2.5]
at
io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:60)
[undertow-servlet-1.3.15.Final.jar!/:1.3.15.Final]
at
io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:131)
[undertow-servlet-1.3.15.Final.jar!/:1.3.15.Final]
at
io.undertow.servlet.handlers.FilterHandler.handleRequest(FilterHandler.java:84)
[undertow-servlet-1.3.15.Final.jar!/:1.3.15.Final]
at
io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:62)
[undertow-servlet-1.3.15.Final.jar!/:1.3.15.Final]
at
io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36)
[undertow-servlet-1.3.15.Final.jar!/:1.3.15.Final]
at
org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:78)
[wildfly-undertow-10.0.0.Final.jar!/:10.0.0.Final]
at
io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
[undertow-core-1.3.15.Final.jar!/:1.3.15.Final]
at
io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:131)
[undertow-servlet-1.3.15.Final.jar!/:1.3.15.Final]
at
io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:57)
[undertow-servlet-1.3.15.Final.jar!/:1.3.15.Final]
at
io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
[undertow-core-1.3.15.Final.jar!/:1.3.15.Final]
at
io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:46)
[undertow-core-1.3.15.Final.jar!/:1.3.15.Final]
at
io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:64)
[undertow-servlet-1.3.15.Final.jar!/:1.3.15.Final]
at
io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:60)
[undertow-core-1.3.15.Final.jar!/:1.3.15.Final]
at
io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:77)
[undertow-servlet-1.3.15.Final.jar!/:1.3.15.Final]
at
io.undertow.security.handlers.NotificationReceiverHandler.handleRequest(NotificationReceiverHandler.java:50)
[undertow-core-1.3.15.Final.jar!/:1.3.15.Final]
at
io.undertow.security.handlers.AbstractSecurityContextAssociationHandler.handleRequest(AbstractSecurityContextAssociationHandler.java:43)
[undertow-core-1.3.15.Final.jar!/:1.3.15.Final]
at
io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
[undertow-core-1.3.15.Final.jar!/:1.3.15.Final]
at
org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61)
[wildfly-undertow-10.0.0.Final.jar!/:10.0.0.Final]
at
io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
[undertow-core-1.3.15.Final.jar!/:1.3.15.Final]
at
io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
[undertow-core-1.3.15.Final.jar!/:1.3.15.Final]
at
io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:284)
[undertow-servlet-1.3.15.Final.jar!/:1.3.15.Final]
at
io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:263)
[undertow-servlet-1.3.15.Final.jar!/:1.3.15.Final]
at
io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:81)
[undertow-servlet-1.3.15.Final.jar!/:1.3.15.Final]
at
io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:174)
[undertow-servlet-1.3.15.Final.jar!/:1.3.15.Final]
at
io.undertow.server.Connectors.executeRootHandler(Connectors.java:202)
[undertow-core-1.3.15.Final.jar!/:1.3.15.Final]
at
io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:793)
[undertow-core-1.3.15.Final.jar!/:1.3.15.Final]
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
[?:1.8.0_121]
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
[?:1.8.0_121]
at java.lang.Thread.run(Thread.java:745) [?:1.8.0_121]
> Can you run the write on its own? I'm wondering if your TDB is broke from
> previous non transactional access.
Yes. As I mentioned, if read and write are not done simultaneously everything
is working correctly. The problem is that at the beginning the service didn't
have many subscribers for writting, but now we do have quite a lot and they are
writing almost every 1 to 10 seconds. Considering that readings takes longer
than that, Houston there is a problem ;)
Thanks a lot.
Jorge
>
> Dick
> -------- Original message --------From: George News <[email protected]>
> Date: 29/12/2017 09:51 (GMT+00:00) To: [email protected] Subject: Re:
> Txn code not handling type of transaction
> On 2017-12-28 18:02, dandh988 wrote:
>> Can you give a complete example? How are you calling MultiUnion? Are
>> you calling txn read on the dataset then building the union, then
>> calling txn write to update the graph?
>
> Let's describe a use case.
>
> 1) I have a dataset that includes 4 named graphs: G1, G2, G3, G4
> 2.a) Someone initiates a sparql request and the internal procedure followed
> is:
> return Txn.calculateRead(dataset, () -> {
> // Create multiunion of 3 namegraphs
> MultiUnion union = new MultiUnion();
> union.addGraph(dataset.getNamedModel("G1").getGraph());
> union.addGraph(dataset.getNamedModel("G2").getGraph());
> union.addGraph(dataset.getNamedModel("G4").getGraph());
>
> Model m = ModelFactory.createModelForGraph(union);
>
> // Launch Sparql query on it
> try (QueryExecution qExec = QueryExecutionFactory.create(query, m)) {
> return ResultSetFactory.copyResults(qExec.execSelect())
> }
> });
>
> 2.b) Someone initiates a sparql request and the internal procedure followed
> is:
> return Txn.calculateRead(dataset, () -> {
> // Create multiunion of 2 namegraphs
> // This code in in a function
> MultiUnion union = new MultiUnion();
> union.addGraph(dataset.getNamedModel("G1").getGraph());
> union.addGraph(dataset.getNamedModel("G2").getGraph());
> Model m1 = ModelFactory.createModelForGraph(union);
>
> // Retrieve namegraph G3
> // This code in in a function
> Model m2 = dataset.getNamedModel("G3");
>
> Model m = ModelFactory.createUnion(m2, m1);
>
> // Launch Sparql query on it
> try (QueryExecution qExec = QueryExecutionFactory.create(query, m)) {
> return ResultSetFactory.copyResults(qExec.execSelect())
> }
> });
>
>
> 3) Someone initiaties a write in G2
> // m stores the new entity model
> Model m;
> Txn.executeWrite(dataset, () -> {
> dataset.getNamedModel("G2").add(m);
> });
>
>
>
> If either version of 2), and 3) are not done in parallel there is no problem
> and everything is executed correctly.
>
> The problem arise when 2.a) or 2.b) is run, and before ending someone tries
> to perform 3). Then I get the FileException("In the middle of an
> alloc-write").
>
> Do you have an idea on how to avoid this? How can I handle transactions in
> this model?
>
>
> I was thinking on creating a global mutex so if any action is being performed
> over the dataset, then the rest would be blocked. The problem here is that
> the code is part of a webservice and then if the read/write operation lasts
> long, I will get a timeout that will close the connection.
>
> The other option is to disable writing while someone is reading. The main
> problem here is how to properly reschedule writings not to have a big queue.
>
> Any help is more than welcome. I don't know what else to do to solve this is
> issue, and the problem is making the service unusable :(
>
> Thanks a lot for the great help you are all offering.
> Jorge
>
>>
>>
>> Dick -------- Original message --------From: George News
>> <[email protected]> Date: 28/12/2017 13:17 (GMT+00:00) To:
>> [email protected] Subject: Re: Txn code not handling type of
>> transaction On 2017-12-27 19:32, Andy Seaborne wrote:
>>>
>>>
>>> On 27/12/17 18:19, George News wrote:
>>>> One think I have forgotten to mention is that I'm using a static
>>>> variable to store the dataset reference. Is this important?
>>>
>>> No.
>>>
>>> The top layer of transaction code uses ThreadLocal variables.
>>>
>>> Internally, there are Transaction objects.
>>>
>>> Andy
>>
>> Another doubt on the issue with transactions. I'm generating
>> Multiunions from the same dataset graphs. While in one thread I'm
>> reading from a multiunion, on another thread I'm writing to one of
>> the graphs included in the multiunion (standalone graph, not
>> multiunion).
>>
>> I have modified my code to use Txn everywhere and still having
>> issues. This is why I'm asking about how multiunions are handle
>> concerning transactions.
>>
>>
>>>>
>>>>
>>>> On 2017-12-27 19:13, George News wrote:
>>>>> Just out of curiosity, just in case the problem is that
>>>>> everything is done in the same thread. Do you know if Wildfly
>>>>> is handling every request under the same thread? I guess not,
>>>>> it will be really strange.
>>>
>>>>>
>>>>> The point is that I have one REST endpoint for writing and
>>>>> another for reading. Writing is done almost per 1 to 10
>>>>> seconds. If I execute a reading that takes longer than that, I
>>>>> get the exception on alloc-write.
>>>>>
>>>>> Thanks a lot. I just don't know why it is happening. Now I
>>>>> think the code is using Txn (I have one point where I copied
>>>>> the Txn.java behaviour) and still got the error.
>>>>>
>>>>> On 2017-12-27 17:18, ajs6f wrote:
>>>>>>> Then nesting is not safe as you might have open initially a
>>>>>>> read transaction and then include a write. If the parent
>>>>>>> one is a write there shouldn't be such an issue (I guess).
>>>>>>
>>>>>> Actual nesting is not supported right now, period.
>>>>>> Transactions in Jena are currently thread-local, so what you
>>>>>> describe above I would see as a mistaken use of the API. If a
>>>>>> client needs to move from a READ to a WRITE transaction, it's
>>>>>> usually appropriate to close the transaction and open a new
>>>>>> one (transactions in TIM, for instance, are snapshot
>>>>>> isolated, and I believe the same is true of TDB2).
>>>>>> Transactional objects _should not_ be passed from thread to
>>>>>> thread with open transactions, unless additional client
>>>>>> machinery is in place to manage those transactions, such as
>>>>>> Dick has described in another thread (using thread proxies).
>>>>>>
>>>>>> Promotion machinery does exist in Jena but I am not aware
>>>>>> that any of the dataset implementations actually support it
>>>>>> right now. I could be wrong about that, since I didn't write
>>>>>> the promotion code. Jena isn't a SQL database and doesn't
>>>>>> offer the same kinds of guarantees or tradeoffs. Correctly
>>>>>> promoting transactions in the absence of information about
>>>>>> data dependencies is non-trivial.
>>>>>>
>>>>>> That having been said, it should be possible to add a
>>>>>> "transaction type" method to transactional objects, within
>>>>>> the "thread-local" design. Some dataset implementations
>>>>>> already have one, e.g. DatasetGraphInMemory::transactionType.
>>>>>> You might want to start by adding it to the
>>>>>> o.a.j.sparql.core.Transactional interface and then "catching
>>>>>> up" the implementation code to build up a PR.
>>>>>>
>>>>>> Adam Soroka
>>>>>>
>>>>>>> On Dec 27, 2017, at 6:53 AM, George News
>>>>>>> <[email protected]> wrote:
>>>>>>>
>>>>>>> On 2017-12-27 12:29, Claude Warren wrote:
>>>>>>>> I recently wrote some code to try to handle a similar
>>>>>>>> situation. In my case I knew I needed a transaction to be
>>>>>>>> active at various points so I created a
>>>>>>>> TransactionHolder. I create the holder and passing the
>>>>>>>> object that has implements Transactional as well as the
>>>>>>>> type of ReadWrite I want.
>>>>>>>>
>>>>>>>> If the transaction is active it does nothing (and I hope
>>>>>>>> the proper transaction has been started) otherwise It
>>>>>>>> starts the transaction. Ad the end I call commit or abort
>>>>>>>> as appropriate. If I did not start the transaction the
>>>>>>>> commit, abort or end is ignored.
>>>>>>>
>>>>>>> I see the same problem in your code as I pointed out
>>>>>>> before. A transaction behaves differently if it is READ or
>>>>>>> WRITE and in your code there is not such a thing. Actually
>>>>>>> the isInTransaction() doesn't give you this information.
>>>>>>>
>>>>>>> Then nesting is not safe as you might have open initially a
>>>>>>> read transaction and then include a write. If the parent
>>>>>>> one is a write there shouldn't be such an issue (I guess).
>>>>>>>
>>>>>>> Just for you to know, your code is more or less integrated
>>>>>>> in [1], so you can "update" your code.
>>>>>>>
>>>>>>> [1]:
>>>>>>> jena/jena-arq/src/main/java/org/apache/jena/system/Txn.java
>>>>>>>
>>>>>>>
>>>>>>>>
>>>>>>>
> I think there may be an issue with abort in that it should
>>>>>>>> probablyset up end() to throw an exception when I have
>>>>>>>> not created the transaction so that the outer
>>>>>>>> transaction will fail.
>>>>>>>>
>>>>>>>> import org.apache.jena.query.ReadWrite; import
>>>>>>>> org.apache.jena.sparql.core.Transactional;
>>>>>>>>
>>>>>>>> public class TransactionHolder { private final
>>>>>>>> Transactional txn; private final boolean started; private
>>>>>>>> final ReadWrite rw;
>>>>>>>>
>>>>>>>> public TransactionHolder( Transactional txn, ReadWrite rw
>>>>>>>> ) { this.txn = txn; this.rw = rw; started = !
>>>>>>>> txn.isInTransaction(); if (started) { txn.begin( rw ); }
>>>>>>>> }
>>>>>>>>
>>>>>>>> public boolean ownsTranaction() { return started; }
>>>>>>>>
>>>>>>>> public void commit() { if (started) { txn.commit(); } }
>>>>>>>>
>>>>>>>> public void abort() { if (started) { txn.abort(); } }
>>>>>>>>
>>>>>>>> public void end() { if (started) { txn.end(); } }
>>>>>>>>
>>>>>>>> }
>>>>>>>>
>>>>>>>>
>>>>>>>> On Wed, Dec 27, 2017 at 11:03 AM, dandh988
>>>>>>>> <[email protected]> wrote:
>>>>>>>>
>>>>>>>>> You cannot nest transactions nor can you promote a read
>>>>>>>>> to a write. You need to rewrite your code or use txn
>>>>>>>>> which correctly checks if a transaction is available
>>>>>>>>> and if not will begin the correct one, either READ or
>>>>>>>>> WRITE.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Dick -------- Original message --------From: George
>>>>>>>>> News <[email protected]> Date: 27/12/2017 10:27
>>>>>>>>> (GMT+00:00) To: Jena User Mailing List <
>>>>>>>>> [email protected]> Subject: Txn code not handling
>>>>>>>>> type of transaction Hi,
>>>>>>>>>
>>>>>>>>> As you know from other threads I'm having some issues
>>>>>>>>> with transactions. Your suggestion is to use Txn
>>>>>>>>> instead of begin/end. Just for curiosity I have checked
>>>>>>>>> the Txn code at [1] and it seems that inside you use
>>>>>>>>> begin/end.
>>>>>>>>>
>>>>>>>>> However I have a doubt concerning how you handle the
>>>>>>>>> begin/end for READ and WRITE. It seems that you open a
>>>>>>>>> transaction based on txn.isInTransaction(), but how do
>>>>>>>>> you know if it is a READ or WRITE?
>>>>>>>>>
>>>>>>>>> If you create something like:
>>>>>>>>>
>>>>>>>>> Txn.executeRead(dataset, { Txn.executeWrite(dataset, {
>>>>>>>>> // Whatever } } }
>>>>>>>>>
>>>>>>>>> the txn.begin(ReadWrite.WRITE) is not called and
>>>>>>>>> therefore it might be leading to unexepected behaviours
>>>>>>>>> for the txn.commit().
>>>>>>>>>
>>>>>>>>> could you give some hints on how this is handle
>>>>>>>>> internally? Before fully modify the code I have, it
>>>>>>>>> might be easier to replicate the txn behaviour ;) but I
>>>>>>>>> would like to know the above (if possible).
>>>>>>>>>
>>>>>>>>> As always, thanks in advanced Jorge
>>>>>>>>>
>>>>>>>>> [1]:
>>>>>>>>> jena/jena-arq/src/main/java/org/apache/jena/system/Txn.java
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>
