This week's book giveaway is in the Agile and Other Processes forum.
We're giving away four copies of The Little Book of Impediments (e-book only) and have Tom Perry on-line!
See this thread for details.
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

close the file AGAIN !

 
Musab Al-Rawi
Ranch Hand
Posts: 231
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi

Andrew suggested in one of the topics using Closable interface to allow us invoke close() by making the Data class implement both DBMain and Closable. this is all possible when you have one instance of database shared by all clients (or when we deal with the standalone case).

but consider this: for each client an instance of Data (which implements sun's interface DBMain) will be created. clients shouldn't have the power to invoke close() & server doesn't have an instance of Main unless we let the server reference an instance of Main just for the purpose of closing the file which sounds i don't know let's say : weak .

some posts suggested that closing the Random Access File is not needed because it is done anyway in "FileChannelImpl" if you check the javadoc of RandomAccessFile you will see that there is mthod getChannel() which return FileChannel, but i didn't find anything about auto-close.

is this thing about auto-close right,
i mean that we don't need to close the file.
 
uzma ali
Ranch Hand
Posts: 56
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
My suggestion would be to close it as even in case of objects which are not pointing to anything are said to be collected by garbage collector but it is always recommended to equate them to null if possible.

and also in randomaccessfile class it is written as

public void close()
throws IOException
This method closes the file and frees up all file related system resources. Since most operating systems put a limit on how many files may be opened at any given time, it is a good idea to close all files when no longer needed to avoid hitting this limit

uzma
 
Edwin Dalorzo
Ranch Hand
Posts: 961
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
In my approach to the problem, I open multiple instances of the underlying database file, that is multiple instances of the RandomAccessFile, but I do not create multiple instances of the database object, that is the Data class.

I run a series of checks to validate that the database file is not corrupted every time I create a Data object. Therefore, creating a instance of Data class per every request would be too expensive, from my humble point of view.

Therefore, what I do, simply, is to let my Data class work with multiple instances of a RandomAccessFile. Every request to the database server opens a new instance of the RandomAccess file, and, at the end of the request, I simply close that instance. I keep track of all instances open just to make sure I am not making a mistake by open files that I do not close.

Wrapping up, from my point of view, it is less expensive to open multiple instances of the RandomAccessFile than opening multiple instances of the underlying Database object, whose initialization might be more costly.

I would be looking forward to your opinions in this regard.
 
Chris Be
Ranch Hand
Posts: 36
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Edwin Dalorzo:
In my approach to the problem, I open multiple instances of the underlying database file, that is multiple instances of the RandomAccessFile, but I do not create multiple instances of the database object, that is the Data class.

I would be looking forward to your opinions in this regard.


Edwin,

I am doing exactly what you are doing: use a unique file handle for each method of my DBAccess implementation that pokes around in the file. This way your file acces does not become a system bottleneck and you don't have to worry about synchronizing on the file handle to ensure concurrent threads are not moving one pointer about the place and interfere with each other's tasks.

I sort of stumbled accross the close issue when I ran my concurrency JUnit test http://www.coderanch.com/t/189353/java-developer-SCJD/certification/JUnit-Test-Cases and then tried to replace the "stuffed up" database file with a fresh copy. I found a million file handles on it, apparently the garbage collector had not yet garbage-collected the R.A.F instances. Explicitly closing each R.A.F file handle resolved this issue. It has the neat side effect that you can replace your database file on the fly while the system stays up for testing. (Note that this may also cause problems in real usage if clients query an available record in the old file, and then book this record which also happens to be available in the new file, when the record contains data that is no longer what is displayed on the screen.)

ChrisBe
 
Musab Al-Rawi
Ranch Hand
Posts: 231
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi,

Thanks for the replies.
well in my case instantiating Data object is not costly at all. The RandomAccessFile is a static member of the Data (pretty much close to Monkhouse's design).

Now when read your posts Suddenly I realize that having multiple file handlers would improve performance (at least in theory, because after all the IO arm will move with every request because we are talking about a normal system with one hard disk).
Edwin if I understood you correctly that means that it's the client's responsibility to close RAF UNLESS it is done Chris's (having a handler for each method) although there is one negative side to it which is opening a file and closing the file for every method call is considered an expensive operation for OS.
but it solves the bottleneck, it solves the problem of closing the file.
i think i will consider changing my design to that after your permission Chris.

Thanks all for sharing your opinions.
 
Edwin Dalorzo
Ranch Hand
Posts: 961
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Of course is not client the one which opens the file. The client could be running in a JVM somewhere at the other side of the world. How could it open the file for the server?

It is the server itself which opens the file per every request.
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic