Thank you Marco and Andy! I perfectly understand that changes made in one JVM will not update the model in second JVM and that this is in general a bad idea :-). We are working on changing the architecture of our application. Meanwhile, let's say I know when the update is done in one JVM and can notify second JVM about the change - will it help to close the model in second JVM and reopen it or reset the model somehow to get the changes made in first JVM?
Alex -----Original Message----- From: Andy Seaborne [mailto:andy.seaborne.apa...@gmail.com] On Behalf Of Andy Seaborne Sent: Sunday, March 10, 2013 20:15 To: users@jena.apache.org Subject: Re: Two tdb instances using same data files On 10/03/13 17:05, Marco Neumann wrote: > Ok yes so this is a very bad idea as mentioned earlier. I would > consider to replace the file access with an endpoint and execute > select and update via SPARQL. Yes, use an endpoint - use Fuseki as a shared database server. It will go wrong otherwise. Even with having an external lock and sync'ing the database inside the exclusive writer lock, does not make it work. The two JVMs will still see inconsistent views of the database, and it will get corrupted. A write action by JVM1 does not update caches in JVM2. Andy
