aspose file tools*
The moose likes Developer Certification (SCJD/OCMJD) and the fly likes B&S: Threadsafety & RandomAccessFile Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of Spring in Action this week in the Spring forum!
JavaRanch » Java Forums » Certification » Developer Certification (SCJD/OCMJD)
Bookmark "B&S: Threadsafety & RandomAccessFile" Watch "B&S: Threadsafety & RandomAccessFile" New topic
Author

B&S: Threadsafety & RandomAccessFile

Daniel Haupt
Greenhorn

Joined: May 22, 2006
Posts: 13
Hi folks,

I've implemented my Data-Class and the locking mechanism as well so far, the JUnit-Tests posted some where in this forum perform fine as well.

I've still got a question according the RandomAccessFile class. Is it threadsafe?

Currently the RandomAccessFile is a instance member of my Data class?

Do I have to synchronize access to the seek, read and write-methods?
Or do you advise to create a new instance of the RandomAccessFile reading my database file in each method of my Data class (create, update, delete)?

Thanks
Daniel
Alex Belisle Turcot
Ranch Hand

Joined: Apr 26, 2005
Posts: 516
Originally posted by Daniel Haupt:
Hi folks,

I've implemented my Data-Class and the locking mechanism as well so far, the JUnit-Tests posted some where in this forum perform fine as well.

I've still got a question according the RandomAccessFile class. Is it threadsafe?

Currently the RandomAccessFile is a instance member of my Data class?

Do I have to synchronize access to the seek, read and write-methods?
Or do you advise to create a new instance of the RandomAccessFile reading my database file in each method of my Data class (create, update, delete)?

Thanks
Daniel


RandomAccessFile is not thread safe, at least not all its methods.

I would personally recommend to create a new instance as a local variable in each method. I find it to be the simplest and best way to ensure that only a single thread is using a specific file pointer at a time.

Even concurrent read might become a problem if you use a single Member variable RandomAccessFile. You need to synchronize, but then not much of concurrent read. Perhaps someone who used a member variable RandomAccessFile could explain why it could be good idea

Check this post: RAF Thread Safe ?

Regards,
Alex
Roberto Perillo
Bartender

Joined: Dec 28, 2007
Posts: 2266
    
    3

Howdy, y'all.

Well, I agree with Alex here. I think the best approach is to use a local variable in each method. This is what I did too. And also, my Data class is a singleton, and all its methods are synchronized, so we can guarantee that no more than 1 thread is reading/writing to the file at a time. I know that it may cause some I/O overhead, but at least it is guaranteed that the file is always in a good shape.

Have a good day, guys!


Cheers, Bob "John Lennon" Perillo
SCJP, SCWCD, SCJD, SCBCD - Daileon: A Tool for Enabling Domain Annotations
Alex Belisle Turcot
Ranch Hand

Joined: Apr 26, 2005
Posts: 516
Originally posted by Roberto Perillo:
And also, my Data class is a singleton, and all its methods are synchronized, so we can guarantee that no more than 1 thread is reading/writing to the file at a time.


Hi,

did your instructions come with synchronized methods ? You are currently not providing concurrent read as (most probably) requires your assignment..
Also, all your methods being synchronized, wouldn't it be pretty much the same as synchronizing on a single member variable RAF..

Please tell me if I'm way off..

Regards,
Alex
[ February 14, 2008: Message edited by: Alex Belisle Turcot ]
Roberto Perillo
Bartender

Joined: Dec 28, 2007
Posts: 2266
    
    3

Howdy, Alex.

did your instructions come with synchronized methods ? You are currently not providing concurrent read as (most probably) requires your assignment..


Well, the instructions didn't come with synchronized methods, but, like unchecked exception, you can add that to your method. Also, I re-read the requirements, and the only part that it mentions concurrency is this one:

"Your server must be capable of handling multiple concurrent requests, and as part of this capability, must provide locking functionality as specified in the interface provided above. You may assume that at any moment, at most one program is accessing the database file; therefore your locking system only needs to be concerned with multiple concurrent clients of your server."

So, as far as I can understand, it means that there are going to be 1 - N clients accessing the server at a time. The challenge is to deal with this concurrency. How the reading of the database is done is "transparent" to the client; so, let's say, if 2 clients perform a search at the same time, it will look like they got the data at the same time, but actually, one got before the other one. I decided to take this approach to avoid any kind of mess in the .db file.

Also, all your methods being synchronized, wouldn't it be pretty much the same as synchronizing on a single member variable RAF..


Hum... almost.
When you first instantiate a RandomAccessFile object, you are ready to read the file. But, I was thinking... when do we get to close the file? Probably when the application is closed... so, when it happens, we could call a close() method... the problem is, the interface doesn't have this method, so this:

DBMain dataHandler = new Data();
dataHandler.close();

wouldn't work.
Also, one good practice is to keep the scope of variables as "restrict" as possible. So, I thought that having a local variable instead of having a class variable would be better.

So, this was my approach, but opinions are always welcome.

Please tell me if I'm way off..


You never are, partner
Alex Belisle Turcot
Ranch Hand

Joined: Apr 26, 2005
Posts: 516
Hi,

I re-read that part in the requirements, and I you are right, they never explicitly say that read must be concurrent..

However, from the sentence you quoted:
Your server must be capable of handling multiple concurrent requests, and as part of this capability, must provide locking functionality as specified in the interface provided above. You may assume that at any moment, at most one program is accessing the database file; therefore your locking system only needs to be concerned with multiple concurrent clients of your server. Any attempt to lock a resource that is already locked should cause the current thread to give up the CPU, consuming no CPU cycles until the desired resource becomes available."


They refer to the locking method of the Interface

Locks a record so that it can only be updated or deleted by this client.
If the specified record is already locked, the current thread gives up
the CPU and consumes no CPU cycles until the record is unlocked.


I interpreted all this as if, making all the thread wait (synchronizing) was not "handling multiple concurrent requests", and since the locking description does not care about read, it should be possible to perform it seamlessly in parallel. That's how I understood it.

But again, I agree when reading it (now) that they never explicitly mention it.

This thread agrees with you: http://www.coderanch.com/t/186277/java-developer-SCJD/certification/All-data-access-methods-synchronized

What do other ranchers think about that ? Is that actually a requirement to allow concurrent read ?

Regards,
Alex
Srini Madireddy
Greenhorn

Joined: May 29, 2008
Posts: 8
Initially i was creating one random access file for each client and had thread safety issues. After reading this thread, i have changed my logic by creating a random access file in each method. now my code is behaving the way i wanted.
Thanks for Alex,Robert.
[ May 30, 2008: Message edited by: Srini Madireddy ]
 
wood burning stoves
 
subject: B&S: Threadsafety & RandomAccessFile