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

Stuck with design question

 
Anonymous
Ranch Hand
Posts: 18944
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi all,
Gosh, I'm stuck with a design question that has bothered me all night. I think I don't see the wood for the trees...
My Data class (URLyBird 1.2.1 to be specific) does delegate all IO operations to a DataFile class which is a wrapper around the RAF. DataFile holds a private static reference to the RAF and synchronizes access to it. I want allow several Data instances as well as several DataFile instances. So far so good - I hope ;-)
How does DataFile know the path to the db file?
If it is passed in the constructor I would have to check whether the file (static reference!) has already been opened because I allow several DataFile instances -> ugly hack.
I could drop the "several instances solution" and have one static reference in Data. This would make sure the constructor is only called one -> lame solution. This simply shifts the problem to the Data class that also needs to know the file path.
DataFile could read the path directly from the properties.file. As a consequence, modification of the file location at runtime would not be possible because the properties file would have to be updated first -> horrible.
Should I maybe go for the Factory Method pattern and provide the file path in the concrete factory method e.g. createDataFile(String path)?
Any helpful comments are welcome.
Best regards,
Marcel
 
Min Huang
Ranch Hand
Posts: 100
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Why not have a method like:

that either
a) opens the file if its not already opened, and then returns the RAF
b) returns the RAF if its already open
As a consequence, modification of the file location at runtime would not be possible because the properties file would have to be updated first -> horrible.

I don't believe this is a requirement for any of the exams. But if you really wanted to do this, then you'd need a method to close the file, and open it again, and have all clients be blocked while this is happening. Of course, it's not a problem for stand alone mode, because only one client is accessing the database file.
For client mode, why would you need this? A client shouldn't be able to choose which database file the server is using and switch it up for all the other clients. The server admin could do this, but he may as well just shut down the server and start it again, as all clients would have been blocked while waiting for the database file to change anyways.
 
Anonymous
Ranch Hand
Posts: 18944
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Min,
The proposed solution with the getFile method is indeed not the worst I can imagine. If I (or all the ranchers out there) can't come up with a smoother solution I'll stick with it. How did you solve this personally?
Thanks for your comments concerning server restart. I need to think more in a KISS-like manner ;-)
Regards,
Marcel
 
Min Huang
Ranch Hand
Posts: 100
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Marcel, I only thought of it because that's the usual way you get an instance of a singleton, and if you only want one instance of the RAF, then...
As for me, my solution was not-so-KISS relatively. My Data class is a singleton, but multiple RAF's are allowed to exist (at first I wanted to use FileChannels, but NIO was a no-no, so I went with lots and lots of RAFs). In fact, each method opens a RAF, and then closes it after exiting. All I did was make sure that the record level locking was airtight so that none of the methods stepped on any of the others' toes.
Check this post: single raf vs. raf per client
I post the gist my scheme in there, and I think the other topics should definitely interest you.
 
Anonymous
Ranch Hand
Posts: 18944
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Min,
I've gone through that thread indeed. Have you compared your multiple RAF solution whith a single RAF solution? My own tests with different number of threads show that a solution with a single static RAF and exclusive access to it (both read and write) is considerabley faster than the one with RAF creation in the various methods on the spot?
Regards,
Marcel
 
Min Huang
Ranch Hand
Posts: 100
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I've gone through that thread indeed. Have you compared your multiple RAF solution whith a single RAF solution? My own tests with different number of threads show that a solution with a single static RAF and exclusive access to it (both read and write) is considerabley faster than the one with RAF creation in the various methods on the spot?

You don't need to worry about performance for this project.
But what do you mean faster? Multiple clients opening files and reading/writing to them will certainly stress the server more, but the clients will perceive the server as being more responsive and thus "faster".
With a single RAF and multiple clients waiting in line to read that RAF, the server experiences less stress, but the clients will perceive the server to be less responsive and "slower".
By the way, I am assuming you synch on your RAF for reading and writing operations (and also making the lock/unlock methods ... placebos?) so only one thread can read/write to the RAF at any one time. I assume this because otherwise there's a whole can of worms you have to open up with the file pointer getting messed up...
[ April 13, 2004: Message edited by: Min Huang ]
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic