This week's book giveaway is in the HTML/CSS/JavaScript forum.
We're giving away four copies of Practical SVG and have Chris Coyier on-line!
See this thread for details.
Win a copy of Practical SVG this week in the HTML/CSS/JavaScript forum!
  • Post Reply Bookmark Topic Watch Topic
  • New Topic

JDOM and Concurrency

 
Vadim Vararu
Ranch Hand
Posts: 147
  • Mark post as helpful
  • send pies
  • 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?
 
Paul Clapham
Sheriff
Posts: 21892
36
Eclipse IDE Firefox Browser MySQL Database
  • Mark post as helpful
  • send pies
  • 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
  • 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.
 
Jelle Klap
Bartender
Posts: 1952
7
Eclipse IDE Java
  • Mark post as helpful
  • send pies
  • 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
  • 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
  • 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.
 
Weeds: because mother nature refuses to be your personal bitch. But this tiny ad is willing:
the new thread boost feature: great for the advertiser and smooth for the coderanch user
https://coderanch.com/t/674455/Thread-Boost-feature
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!