Andy, Thank you for your answer. We have about 10,000,000 triples in the data files. We will work on architecture changes. Meanwhile, if we take the "close-reopen" way, what is the best way to completely close the model?
Thank you, Alex -----Original Message----- From: Andy Seaborne [mailto:a...@apache.org] Sent: Monday, August 19, 2013 16:06 To: users@jena.apache.org Subject: Re: Two tdb instances using same data files On 19/08/13 13:21, Shapiro, Alexander wrote: > Hi, > A while ago I've asked a question about two tdb instances using same data > files (see below). > Now I'm using the following code to open a model on both instances: > SystemTDB.setFileMode(FileMode.direct); > TDBMaker.setImplFactory(TDBMaker.uncachedFactory); > model = TDBFactory.createModel(shared_location); > > The problem is that sometimes when I do some changes on one instance - they > are seen in another instance and sometimes are not. > So I have two questions - > 1. How it is possible when I do not use any cache? **** This is a very bad idea **** **** Share a single data server **** You are using per-dataset caches - uncachedFactory is just about caching of built datasets in the same JVM, not about caching inside a dataset. I'm not guaranteeing this wil work at all. It's madness to update files on disk from two different JVMs and expect any kind of consistency or safety. I suggested it might work to close a dataset on update (actually a sync is sufficient) and have the other JVM close-and-reopen it. How you coordinate that is hard and must be done very carefully. The other JVM can't be reading the database between the update starting and being told to close-reopen. If you are inconsistently seeing changes, then maybe one or more of: (1) You are not (2) You are on 64 bit (and not using transactions?) Memory files may means that changes can be flushed at any time. (3) You are on 32 or 64 bit and the second JVM is reading at the same time as the updating JVM. You can't stop an inconsistent set of changes being seen in models in the second JVM unless you coordinate a switch over. > 2. Is there any way to solve this problem? Changing the architecture of your application. Share a single data server. Anything else is unlikely to be anything other than an unreliable fudge. ----------------- How much data do you have? There are two designs that are good: 1/ SPARQL Query/Update to a shared Fuseki server. 2/ Use Graph Store Protocol to PUT/GET models from a shared server. Andy > > Thank you, > Alex > > > -----Original Message----- > From: Alex Shapiro [mailto:alex.shap...@dbmotion.com] > Sent: Monday, March 11, 2013 16:58 > To: 'users@jena.apache.org' > Subject: RE: Two tdb instances using same data files > > Thank you, Andy! > I will try this. > > Alex > > -----Original Message----- > From: Andy Seaborne [mailto:andy.seaborne.apa...@gmail.com] On Behalf > Of Andy Seaborne > Sent: Monday, March 11, 2013 15:46 > To: users@jena.apache.org > Subject: Re: Two tdb instances using same data files > > On 11/03/13 11:29, Alex Shapiro wrote: >> 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 > > "bad idea" is an understatement! > > This might work: > > Close the dataset and force it out of the dataset cache. > TDBMaker.releaseDataset > > But it's probably better to uncached datasets in the first place: > > TDBMake.setImplFactory(TDBMaker.uncachedFactory) > > No guarantees whatsoever. > > Andy > > >
