Hi Morten,
The way TDB works, only one application can have the database files at
he same time. I suspect that the checking TDB performs (you get an
error if multiple access is deteched) is being defeated by running two
webapps in the same, but partition, glassfish instance. The test, IIRC,
is "same process id", which it is for two instances in glassfish.
TDB uses a number of statics to manage shared access to the database.
TDBFactory returns the same database for a location every time. But if
a class is loaded twice by different classloaders, there are different
statics.
The way to update a database is through the web facing side with SPARQL
Update or the SPARQL Graph Store protocol. Can your updating .war send
requests to Fuseki?
A more complicated setup would be to have one .war to do all the TDB
access and have a special Fuseki service that knows to send requests to
that 3rd DB-manager .war. That would take new code.
Andy
On 05/05/15 20:58, Yarc Yarc wrote:
Hello,
I'm trying to use fuseki for querying live data managed by a web
application. This generally works, but I seem to have a caching problem
with my fuseki. This is the setup;
a. I'm running the fuseki.war over glassfish 4 configured with a dataset
fethced from a TDB file system folder for persistence. That works well it
seems. Data is read from the TDB folder and I can query over port 3030.
b. I have another .war application running in the same glassfish instance.
This .war uses the same TDB folder for persistence. The application queries
and updates the TDB folder. The data is persistent in that if I undeploy
the application and redeploy the data is still there.
Now, if the application in b. inserts new data, then this is not reflected
in the fuseki application (a). If I, however, undeploy and redeploy
fuseki.war then the new data from b. is there.
My initial hypothesis is that fuseki uses a cache at some level, so that if
the underlying TDB file store changes, it is not picked up. Is this a
reasonable hypothesis?
If so, is there some way I might circumvent this behaviour - i.e. can I
enforce a TDB sync before each query in Fuseki somehow?
If not, then I'm probably confused and I'm asking for a friendly hint on
where I go wrong.
I have read the caching and synchronization section in the documentation (
https://jena.apache.org/documentation/tdb/java_api.html), generally googled
this issue (e.g. "fuseki cache" or "share TDB store") and I'm aware of the
single-jvm constraints on TDB (
https://jena.apache.org/documentation/tdb/tdb_transactions.html) as well as
a suggested pattern of letting all other clients of a TDB store go through
fuseki if I understand it correctly (
http://answers.semanticweb.com/questions/28629/sharing-jena-tdb-data-store).
Any and all help is appreciated.
:-)
M.
------ a few excerpts on how b. relates to TDB, commits and the dataset
-----
I create my dataset like this:
dataset = TDBFactory.createDataset(datasetdir);
Before each sparql insert I do
dataset.begin(ReadWrite.WRITE);
After each sparql insert I do
try {
dataset.commit();
} catch {
...} finally {
dataset.end();
}
