• Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

NX: FileChannel & ThreadSafety

 
Bob Reeves
Ranch Hand
Posts: 64
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi All:
The FileChannel Javadoc says "File channels are safe for use by multiple concurrent threads." I take this to mean the FileChannel object is thread-safe (ie., the positioning, etc), but the FileChannel write/read operations require a higher level protocol for thread-safety of their target file. After all, the FileChannel we're using is probably from RandomAccessFile. And RandomAccessFile doesn't guarantee any thread safety.
Anyone have authoritive information or reference on this?
Tx
 
Max Habibi
town drunk
( and author)
Sheriff
Posts: 4118
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Bob,
There are several discussions on this forum, and some very specific information in my book about this topic. To sum it up, if you access your RandomAccessFile using a FileChannel, then you get the ThreadSafe behaviour, as described. Otherwise, you don't.
All best,
M
 
Bob Reeves
Ranch Hand
Posts: 64
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Max:
Thanks for the response!
I reviewed page 284 of the book you co-authored and see your point. The sentence fragment "specify a position at which to begin writing" I interpret to mean FileChannel from RandomAccessFile is NOT atomic if you use the write(ByteBuffer, position) method (there are two ways to specify a position). However, if you do a write(ByteBuffer, position) followed by a position(newPosition), then by virtue of the block, it is. On a multi-head disk drive that can write simultaneously to multiple tracks, this is interesting behavior!
Is this behavior documented by SUN? Is this contract behavior of the methods? Interestingly, if I do a force(false) after my writes to the database -- after a write(ByteBuffer, position) -- things seem to work unreliably. I would have expected them to work better, but more slowly.
Tx
 
Bob Reeves
Ranch Hand
Posts: 64
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi All:
I started hammering my URLyBird database through the RMI connection to test lock and data integrity. All seems to work well. Unlike what I wrote earlier, there is not problem with force(false)!
A bit is a terrible thing to lose ...
Tx
 
Max Habibi
town drunk
( and author)
Sheriff
Posts: 4118
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
That's pretty much what I expected. I'm interested in knowing how this goes forward for you: keep me posted.
M
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic