Looking at FileChannel it has the following part in its documentation: The view of a file provided by an instance of this class is guaranteed to be consistent with other views of the same file provided by other instances in the same program. The view provided by an instance of this class may or may not, however, be consistent with the views seen by other concurrently-running programs due to caching performed by the underlying operating system and delays induced by network-filesystem protocols. This is true regardless of the language in which these other programs are written, and whether they are running on the same machine or on some other machine. The exact nature of any such inconsistencies are system- dependent and are therefore unspecified.
This looks exactly like the guarantee I need, now I've looked into RandomAccessFile.getChannel() implementation and it holds a single member of FileChannel which is initialized on demand and the next calls will return the same instance. So the only way I see to create multiple FileChannel instances over the same file is to open multiple RandomAccessFile instances over that file and use getChannel() on each of these instances. Since FileChannel does provide this guarantee I tend to believe it relies upon a guarantee that RandomAccessFile provide, otherwise it would need some mechanism to identify that different FileChannel instances over different RandomAccessFile instances are actually over the same file in order to provide the specified guarantee. What do you think? On Dec 21, 9:33 am, Ben Schulz <ya...@gmx.net> wrote: > My guess is that Java IO takes advantage of any OS optimizations there > are, on another OS there may be a per-file-pointer cache or something. > That would obviously invalidate your assumptions. I suggest you look > into using asynchronous I/O which will get rid of any multiple-reader- > bottlenecks. This should also rule out third parties tampering with > the file (since you already hold the write lock). > > With kind regards > Ben > > On 21 Dez., 07:50, Eitan <eitan...@gmail.com> wrote: > > > I am trying to avoid locking the access to file for multiple readers > > can be multi concurrent readers and it will be a bottleneck. > > I've created a multi threaded test for it and it seems to work fine, > > but I am not still not confident about it. I was hoping to find some > > documentation about it which specifies the behavior. > > > On Dec 20, 11:40 pm, Christian Catchpole <christ...@catchpole.net> > > wrote: > > > > Can you even get a second lock on a file that way? Sounds dangerous. > > > I would just create a some kind of service that each Thread can access > > > that will synchronise disk access down to one RandomAccessFile. > > > > On Dec 21, 2:48 am, Eitan <eitan...@gmail.com> wrote: > > > > > I want to use a file in a single process with single writer or multi > > > > readers mutual exclusion, for that purpose I use number of > > > > RandomAccessFile instances over the same file which are open in read > > > > mode and are used concurrently. I also have a single RandomAccessFile > > > > open in "rw" mode which updates the file (not when it is being > > > > actively read). > > > > I do not close the Random Access File handles at any point. > > > > > I wanted to know if the data which is being written to the file with > > > > the RandomAccessFile in rw mode will always be visible to the readers > > > > after the the write is complete? > > > > (I am not using rws mode for performance issues, only for these > > > > readers which are in the same process). > > > > > Thanks > > > > Eitan -- You received this message because you are subscribed to the Google Groups "The Java Posse" group. To post to this group, send email to javapo...@googlegroups.com. To unsubscribe from this group, send email to javaposse+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/javaposse?hl=en.
