• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

RandomAccessFile and synchronization issues.

 
Ranch Hand
Posts: 159
IntelliJ IDE Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi all,

The access to my RandomAccessFile is not synchronized. I'll try to explain why I think that is not necessary.

My Data class implements an extended Sun interface which has some additional methods. Let's call them readDatabase and writeDatabase. The Data class has some kind of worker class for handling the file I/O, working with the RandomAccessFile. (The Data class also has a worker class for logical record locking, which is not important here).

When the stand-alone client or the server instantiates the Data class (started from the business layer) this happens:

* At constuctor:
- create new worker for logical record locking
- add shutdownhook thread which makes two call at shutdown: writeDatabase in the worker class and close the RandomAccessFile

After creating the Singleton Data instance a readDatabase will be called (with the by the client specified database location), which will read all the records in a Map<Integer, String[]>. This content will be the record map in the Data class that is used as a record cache. Manipulation of this record cache (read, find, update, delete, etc) is handled by a ReentrantReadWriteLock.

When the stand-alone client or the server window closes, the shutdownhook thread will write all the records back to file and close the RandomAccessFile.

So I think in my current implementation both the readDatabase and writeDatabase don't have to be synchronized. But if the record cache implementation is replaced by directly working on the datafile then its access should be synchronized.

Maybe I just have to add the keyword synchronized to both my readDatabase and writeDatabase methods in the worker class handling file I/O?

Can anyone comment on this. I'm afraid to make a stupid mistake which will result in a failure (and then in a much more expensive exam...course and stuff..deadline coming up).
 
Sheriff
Posts: 11604
178
Hibernate jQuery Eclipse IDE Spring MySQL Database AngularJS Tomcat Server Chrome Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
So if I understand correctly you have declared 2 extra methods in a custom interface (extending the given interface). These methods will fill your record cache with records from the database file (at startup) and write the records from the record cache back to the database file (at shutdown).

If all other methods just operate on your cache, you don't need a RandomAccessFile as instance variable. If you just store the dbPath and create a RAF in these 2 methods, you are using local variables which are always thread-safe
And what happens if I invoke the readDatabase 2x in a row? Same question for the writeDatabase? What happens if I call read-method before readDatabase (or after writeDatabase)? These methods are part of the public api (because defined in an interface), so these situations are possible and should be handled.
 
Dennis Grimbergen
Ranch Hand
Posts: 159
IntelliJ IDE Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Roel De Nijs wrote:So if I understand correctly you have declared 2 extra methods in a custom interface (extending the given interface). These methods will fill your record cache with records from the database file (at startup) and write the records from the record cache back to the database file (at shutdown).


Correct

Roel De Nijs wrote:
If all other methods just operate on your cache, you don't need a RandomAccessFile as instance variable. If you just store the dbPath and create a RAF in these 2 methods, you are using local variables which are always thread-safe


Hehe thnx, that is a nice solution. Local variables are always thread safe...problem solved!

Roel De Nijs wrote:
And what happens if I invoke the readDatabase 2x in a row? Same question for the writeDatabase? What happens if I call read-method before readDatabase (or after writeDatabase)? These methods are part of the public api (because defined in an interface), so these situations are possible and should be handled.


Hmm yes I need to take care of these as well (although some code shouldn't be invoked twice). But how to nicely solve that? Declaring a boolean that indicates if the database is already read into cache? But then you need to check in every method (like read, update, delete, etc) for that boolean value. I don't know if that is a great solution.
 
Roel De Nijs
Sheriff
Posts: 11604
178
Hibernate jQuery Eclipse IDE Spring MySQL Database AngularJS Tomcat Server Chrome Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Dennis Grimbergen wrote:But how to nicely solve that? Declaring a boolean that indicates if the database is already read into cache? But then you need to check in every method (like read, update, delete, etc) for that boolean value. I don't know if that is a great solution.


That's a possibility. Or you could just do the same check based on your dbPath (if it is set, db is running; otherwise it's not). You just have a private method which does the check (and throws an IllegalStateException for example when not ok). This method is invoked from each method (if necessary). Sounds a clean solution to me.
 
Consider Paul's rocket mass heater.
reply
    Bookmark Topic Watch Topic
  • New Topic