Not misleading - I was just talking about the standard file objects,
not these channels. So this might be your answer then.
On Dec 26, 6:36 pm, Eitan wrote:
> So do you think that the FileChannel documentation is misleading?
>
> "The view of a file provided by an instance of this class is
> guar
So do you think that the FileChannel documentation is misleading?
"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"
This is taken from the javadoc of FileChannel.
Thanks
On D
Well, as you are finding, this "simple" approach is causing you
problems. The only thing I can add is to just be cautious about
relying on side-effects or presumptions about these multiple readers.
Because they could change at any time. I've never considered such an
approach because I have always
Because it's a simple feature that I need and I don't want an overkill
solution that I do not control its thread count, its memory
consumption and cpu usage.
It is just a simple component inside my highly performance server that
needs to keep a single list of redo log in the disk if it takes to
muc
Because it's a simple feature that I need and I don't want an overkill
solution that I do not control its thread count, its memory
consumption and cpu usage.
It is just a simple component inside my highly performance server that
needs to keep a single list of redo log in the disk if it takes to
muc
Why a file mate?
Why not Redis, Cassandra, MongoDB, SQLite whatnot?
On Fri, Dec 25, 2009 at 10:20 AM, Eitan wrote:
> What about what I said above, using multiple FileChannel/
> RandomAccessFile to read from the same file (not writing, there's a
> single writer multi reader mutual exclusion prote
What about what I said above, using multiple FileChannel/
RandomAccessFile to read from the same file (not writing, there's a
single writer multi reader mutual exclusion protection over these
FileChannel/RandomAccessFile access), all I am worried about is the
visibility that updates the writer will
Is not the simplest solution to allow each thread to get a reference
to the *single* RandomAccessFile instance and simply synchronize on it
while reading (not forgetting to reset the offset into the file).
It's not going to be super performant, but how is it ever going to be
with multiple threads t
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 ma
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
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 sp
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 wrote:
> I want to use a file in a single process with single writ
12 matches
Mail list logo
