JENA-1667 and others.

Presumably this is more than one TDB database.

What works is when graphs are in the same database.

Each database is it's own transaction system so working across them is going to be difficult to provide in the most general case.

What might be better is define the ja:RDFDataset to have the graphs, then query the union graph of the dataset. But that again is crossing multiple transaction systems so may not work.

    Andy

On 11/09/2019 10:07, Laura Morales wrote:
For what it's worth, 3.7.0 does seem to work as well. On the other hand, 3.8.0, 
3.9.0, 3.10.0, 3.11.0, 3.12.0, none of them work, they return the same error. 
It looks like as if something was introduced between 3.7.0 and 3.8.0 that broke 
the UnionModel and transactions.

Could somebody please suggest to me how to setup a working UnionModel with 
Fuseki 3.12.0? Thanks!




Sent: Wednesday, September 11, 2019 at 10:46 AM
From: "Laura Morales" <laure...@mail.com>
To: users@jena.apache.org
Cc: users@jena.apache.org
Subject: Re: "not in a transaction", but only sometimes

Forgot to mention: Fuseki 3.12

I fear guys that you've introduced a new regression in 3.12.0 regarding the 
UnionModel/transactions/TDB. I've spent hours debugging my code and Fuseki 
configuration, until I noticed that my dev server was 3.6.0 but in the prod 
server I had installed 3.12.0 (the last version). Reverting to 3.6.0 works 
without problems. Reverting once more to 3.12.0, the problem is there again.

To give some context, I have a very basic UnionModel as described in the previous email. 
What I need is a union graph of graphs extracted from several TDB datasets (I would like 
to use TDB2 but it does not support this feature, so all my datasets are TDB). I'm 
running a DESCRIBE query that extracts data from the union, data that is stored in 2 
graphs. With 3.6.0 it works. With 3.12.0 I receive a 500 and Fuseki's logs show me 
"Not in a transaction". This query however does work sometimes, in particular 
if I run it alone. I see the problem when I run it after other queries in sequence. No 
data is ever altered, they are all read-only queries (ASK/DESCRIBE). I really don't know 
what's going on.

Reply via email to