Win a copy of The Little Book of Impediments (e-book only) this week in the Agile and Other Processes forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

NX: synchronizing read/write

 
Xavier Fabreguettes
Greenhorn
Posts: 14
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi,
My assignment is the contractors one. I want to perform my reads without caching and would like you to clarify a few points about the impact multithreading could have on my approach. I am not worried about writing to the DB as the locking process is here to take care of concurrent updates. What I would like to know is when performing a read, how can I guarantee that between the moment I position my cursor (for either a RandomAccessFile or a FileChannel) and the moment I read, no other thread is going to change the cursor's position by either reading or writing another record? I understand that at least if I use FileChannel, the actual read won't be messed up with i.e. no thread is going to change the cursor between the moments the first byte and the last byte I am interested in are read. My concern is how to be sure that between the 2 lines of code in my read function:
- position cursor
- read record
the 'ownership' of the file is not going to be handed over?
When using locks for update, we can set up the cursor location and carry out the update within the same block, knowing that no other thread is going to update the record as all updates apply the same locking mechanism. However, I think that a read could possibly interfere with the update as it doesn't use the same mechanism. I am not sure that synchronizing the read function or synchronizing on the FileChannel (or underlying RandomAccessFile) would achieve anything as, because of the locking mechanism itself, writing records doesn't require synchronizing anything. Any idea anybody? Please let me know if I am missing anything very obvious or - more likely - if I didn't understand correctly how multithreading works.
If possible, I would really like to avoid using caches: I don't want to start again the debate about caching v. no caching, I just want to know if there is a solution to my problem.
Thanks a lot for your help.
Xavier
 
Andrew Monkhouse
author and jackaroo
Marshal Commander
Pie
Posts: 12014
220
C++ Firefox Browser IntelliJ IDE Java Mac Oracle
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Xavier,
If you have a single instance of a class to do your file IO operations, then you can synchronize the methods in that class, then only one method at a time will be able to set the file pointer and do it's operation.
The locks are not intended to handle thread safety of your file IO operations. The locks give you a way of ensuring that a record can be modified before you modify it. That is, if two clients both try and book the same record at the same time (so they both click their buttons at almost the same instant) then one should be able to book the record, and the other one should find that the record has been booked, and get an error message. To handle this properly you need record locking. It has nothing to do with file pointer positioning.
Regards, Andrew
 
Xavier Fabreguettes
Greenhorn
Posts: 14
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Andrew,
Thanks for your reply. Yes, I totally agree with your 2nd paragraph, what I meant was that as you are sure taht nobody else is in a position to modify the DB when your thread is about to do it, CONSEQUENTLY the updation will be thread safe. I was aware that the locking mechanism is not a customised way to implement thread safety.
I do use a singleton and have therefore only one instance of the database. The thing if that initially I had made my read method synchronized and my update one not (because of the lock menchanism), but I can see now that having my update method synchronized should be enough. Is preferable to synchronize on the file object (RAF or FileChannel) or to have the whole update method synchronized?
Once again, thanks for your help.
Kind regards,
Xavier
 
Philippe Maquet
Bartender
Posts: 1872
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Xavier,
The thing if that initially I had made my read method synchronized and my update one not (because of the lock menchanism), but I can see now that having my update method synchronized should be enough.

Both methods (read and update) should be synchronized IMO.
Regards,
Phil.
 
Andrew Monkhouse
author and jackaroo
Marshal Commander
Pie
Posts: 12014
220
C++ Firefox Browser IntelliJ IDE Java Mac Oracle
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Xavier
Is preferable to synchronize on the file object (RAF or FileChannel) or to have the whole update method synchronized?

Yes
Ideally you want synchronization for as little time as possible. So if there was some work that the methods could do that did not require synchronization, then you might consider using a synchronized block for just the actions that require synchronization.
But if there is no such additional work that could be done outside of synchronization, then it might make life easier for the junior programmer if the entire method is synchronized.
Time for you to make a design decision.
Regards, Andrew
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic