0

I am using an RDF file to store links (URLs) of online resources that are added by different users about various topics.

I am using Jena API to read and write the RDF file, on Apache server.

My concern is that multiple users would allowed at the same time to login to the system and may interact with the file at the same time.

I am wondering if this would cause any problem in updating the file, for example, will it corrupt the file in some way. Can I go ahead with this for live application or will it crash my application as a result of RDF file being accessed by multiple users for read and write at the same time.

I would really appreciate the help.

Thanks

Syed

 //updated code to understand answer.
 // Example of Locks for reading

File f = new File(fileName); 
InputStream in = new FileInputStream(f);

Model model = ModelFactory.createDefaultModel();                
model.read(in,null);
String queryString = "...";


model.enterCriticalSection(Lock.READ);  // use of lock
try {

     qe = QueryExecutionFactory.create(qry, model);
     rs = qe.execSelect();
     for ( ; rs.hasNext() ; )
     {
         //read literals
         //read literals
         out.println(....);
     }
     qe.close();

 } finally 
   {
     model.leaveCriticalSection() ;
   }

//******************************
// Example of Locks for WRITING


File fout = new File(fileName); 
Model model = ModelFactory.createDefaultModel();                
model.read(in,null);
OutputStream os = new FileOutputStream(fout);
// model updation
// new triplets. new data being added

model.enterCriticalSection(Lock.WRITE);  // use of lock
try {
             model.write(os);
    } finally 
   {
     model.leaveCriticalSection() ;
   }

os.close();
Vadim Kotov
  • 8,084
  • 8
  • 48
  • 62
SotonJ
  • 327
  • 1
  • 3
  • 10

2 Answers2

2

Have a look at the Concurrency HowTo of the Jena website. Follow relevant links for TDB/SDB transactions. According to the documentation:

Locks provide critical section support for managing the interactions of multiple threads in the same JVM. Jena provides multiple-reader/single-writer concurrency support (MRSW).

The pattern general is:

Model model = . . . ;
model.enterCriticalSection(Lock.READ) ;  // or Lock.WRITE
try {
    ... perform actions on the model ...
    ... obey contract - no update operations if a read lock
} finally {
    model.leaveCriticalSection() ;
}
chris
  • 1,787
  • 1
  • 13
  • 13
  • Thanks a lot for you answer. I have updated the question with example from my code for both read/write locks . Do you think I rightly understood the concept of locks and I can do exactly the same in my code and this should solve my problem. What I understand is that I can use these lock with files, and I should read lock around code where I execute SPARQL and iterating resultset. I can use write lock where I would write the model after updating. Thank you very much. – SotonJ Jun 06 '15 at 09:49
  • that's about right. you may want to give TDB/SDB a go though, as they offer full ACID transaction support. file storage as in your example is probably only useful for prototyping/testing afaic. – chris Jun 06 '15 at 17:58
2

File storage does not offer proper transactions.

The choices are:

  1. Use TDB transactions -- needs datasets
  2. Use Concurrency HowTo -- works on models.
  3. Use DatasetGraphWithLock -- provides a lock-based transaction simulation (imperfect - no abort).

If you locking, do remember that writing a file is not atomic. A crash in the middle of writing leaves half a file behind. Write to one file then rename it to the final name within the same directory.

AndyS
  • 16,345
  • 17
  • 21
  • Thank you for you answer. So are you suggesting the Locks should not be used when using RDF data in RDF files. I have already seen that the files would be left half written. And that is why I am worried that there may be problems with using files. I have updated my question with example from my own code for read and writing lock. Please advice, if I should go ahead with this. Maximum 20-22 people will use the application at the same time. – SotonJ Jun 06 '15 at 09:52