• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

JDOM and Concurrency

 
Ranch Hand
Posts: 147
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hello everybody. I'm studying JDOM API now and such a question has appeared in my mind.

Id JDOM API thread safe? For instance, if i use it in a web-application, to read some properties from and xml file (something like web.xml)...won't i have problems if 3-4 people try to access the file at the same time? What about the writing to file?

Are all that operations thread safe, or should i syncronize them?
 
Marshal
Posts: 28193
95
Eclipse IDE Firefox Browser MySQL Database
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
There aren't going to be any problems if several users read a file at the same time. They all get the same data. It doesn't matter how many people try to read it at the same time.

As for modifying a shared file from a web application, just don't do that. If you do, the problems to be solved are much greater than whether the parser is thread-safe.
 
Vadim Vararu
Ranch Hand
Posts: 147
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Paul Clapham wrote:There aren't going to be any problems if several users read a file at the same time. They all get the same data. It doesn't matter how many people try to read it at the same time.

As for modifying a shared file from a web application, just don't do that. If you do, the problems to be solved are much greater than whether the parser is thread-safe.





Yeap...but, for example, if the file will not be supposed to be modified by many users at the same time (let it be a config file, modified just by one person, admin or anybody else via CMS)..... Is my own syncronization gonna be the best variant? Actually, i don't see other posibilities, besides let the file without any write syncronization, or do it by myself. But, because there will be an extremelly small chance that two write requests will go together, i guess the best variant is to do the syncronization, or what?

What can you say about this.
 
Bartender
Posts: 1952
7
Eclipse IDE Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I guess you could use a RandomAccessFile to obtain a read/write FileChannel for a particular file, and use that FileChannel to try and obtain a lock on the file before you attempt to write to it. That way if the file is already locked an exception should be thrown, which you can handle to indicate to the user that the file in question is already being editted by some other user/process, and to try again later. If you don't get any exceptions and thereby succesfully obtain a lock, you should be free to edit it without any problems, until the lock is released.
 
Vadim Vararu
Ranch Hand
Posts: 147
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Jelle Klap wrote:I guess you could use a RandomAccessFile to obtain a read/write FileChannel for a particular file, and use that FileChannel to try and obtain a lock on the file before you attempt to write to it. That way if the file is already locked an exception should be thrown, which you can handle to indicate to the user that the file in question is already being editted by some other user/process, and to try again later. If you don't get any exceptions and thereby succesfully obtain a lock, you should be free to edit it without any problems, until the lock is released.




What's the final difference between this and syncronizing an access method (one that will write to file)?
 
Jelle Klap
Bartender
Posts: 1952
7
Eclipse IDE Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
The fact that it's an existing, tested and proven solution that's part of the standard Java API. This approach can also keep other (non-Java) applications, beside the Java application that locked the file, from concurrently modifying the locked file. Although adherence to the locked-state depends on the OS and the application trying to access the file (read the FileChannel's Javadoc for more information). It also offers finer grained concurrency options (should the need arise), like locking only specific parts of a file (sharing a file lock), although that particular bit of functionality is OS dependent as well. It just seems unneccesary to develop your own file locking mechanism if a perfectly suitable standard one already exists.
 
With a little knowledge, a cast iron skillet is non-stick and lasts a lifetime.
reply
    Bookmark Topic Watch Topic
  • New Topic