 |
 | Home | Contact Us | FAQ | Search & Site Map | Link to Us |
 | Sign In | Join | Other 45 Sites in Network |
Java Forum / General / July 2007Reading while writing
If there's a java process writing to a file and another java process reading from it - what happens? Does the reader take it what's currently been written or what? Does the OS deal with this in some way - like giving a before-write copy of the file? > If there's a java process writing to a file and another java process > reading from it - what happens? Does the reader take it what's currently > been written or what? Does the OS deal with this in some way - like > giving a before-write copy of the file? It depends on the OS (or, more likely, the filesystem driver). Most filesystems would probably hold a read-write lock on the file, creating a race condition. >> If there's a java process writing to a file and another java process >> reading from it - what happens? Does the reader take it what's currently [quoted text clipped - 4 lines] > filesystems would probably hold a read-write lock on the file, creating a > race condition. So there's most likely a block on the file? Doesn't seem the best way of dealing with the situation. A guess we're going under java here a bit? >> If there's a java process writing to a file and another java process >> reading from it - what happens? Does the reader take it what's currently [quoted text clipped - 4 lines] > filesystems would probably hold a read-write lock on the file, creating a > race condition. I think most filesystems would throw an error, or more likely, scramble the data. The application should employ locking to ensure that a region of a file is changed in an orderly manner. Java NIO has a FileLock object. Try that. >>> If there's a java process writing to a file and another java process >>> reading from it - what happens? Does the reader take it what's currently [quoted text clipped - 11 lines] > is changed in an orderly manner. Java NIO has a FileLock object. Try > that. There was a recent thread discussing that Java file locks may be advisory only, depending on how the underlying OS implements file locks.  SignatureLew > There was a recent thread discussing that Java file locks may be > advisory only, depending on how the underlying OS implements file locks. Write once, test everywhere. Just great. The Java Doc says this about FileLock: " Whether or not a lock actually prevents another program from accessing the content of the locked region is system-dependent and therefore unspecified. The native file-locking facilities of some systems are merely advisory, meaning that programs must cooperatively observe a known locking protocol in order to guarantee data integrity. On other systems native file locks are mandatory, meaning that if one program locks a region of a file then other programs are actually prevented from accessing that region in a way that would violate the lock. On yet other systems, whether native file locks are advisory or mandatory is configurable on a per-file basis. To ensure consistent and correct behavior across platforms, it is strongly recommended that the locks provided by this API be used as if they were advisory locks. " Which to me implies that one should test for a lock first. Writing data to a locked region and expecting an error to be thrown may not produce an exception, just bad data. So it should all still work, you just have to test for locks first. Correct? > To ensure consistent and correct > behavior across platforms, it is strongly recommended that the locks [quoted text clipped - 4 lines] > an exception, just bad data. So it should all still work, you just have > to test for locks first. Correct? Correct. And note that Unix 'mandatory' locks, where implemented, would only have made the situation worse. With Unix mandatory locks, if the writer hadn't tried to acquire the lock first, the write would be merely *delayed* until the lock was released by whoever had it, *ensuring* a data corruption (because the non-cooperative update occurred after the cooperative update). By contrast, that non-cooperative write() on a Windows machine would have given an error immediately, which is the only sensible behaviour. You must always test and set file locks in all parts of an application that want to share a file, and *never* rely on Unix mandatory locking even when you know it exists. On Thu, 19 Jul 2007 23:54:03 GMT, "Crouchez" <blah@bllllllahblllbllahblahblahhh.com> wrote, quoted or indirectly quoted someone who said : >If there's a java process writing to a file and another java process reading >from it - what happens? Does the reader take it what's currently been >written or what? Does the OS deal with this in some way - like giving a >before-write copy of the file? A mess. The file will look to the reader the length it had at the last flush or close. For than sort of thing you normally use a TCP/IP stream. SignatureRoedy Green Canadian Mind Products The Java Glossary http://mindprod.com you see, this has always got me about java development - there's always one eye on the os platform - the java layer always depends on what's going on underneath - and much of the time you won't have a clue - most of the meaty stuff is closed off in native methods Free MagazinesGet these publications absolutely FREE for up to 12 months. There are no hidden fees and no obligation. Simply choose a title, complete the application form and submit it. Read more ...
|
Reply to this Message
|
 Sign In
 Join
 My Latest Posts My Monitored Threads My Blog My Photo Gallery My Profile My Homepage Start New Thread Enable EMail Alerts Rate this Thread
|
©2009 Advenet LLC Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.