• Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

B&S Data.java

 
Titus Barik
Greenhorn
Posts: 24
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I am currently just starting out and trying to implement my Data.java
access class. I am following the KISS principle: I'd rather have a
clear and simple, slower solution than a complex, fast solution that
is prone to bugs.

Thus, for simplication, there is no caching of the data, and no
NIO. There's also no fancy singleton patterns and a single table is
assumed.

My implementation is as follows:

Data.java:

RandomAccessFile raf;
HashMap locks;

Data(..):
initialization (raf mode rwd)
validates magic cookie

synchronized read(int recNo):
reads the raf directly and gets the record

synchronized update(int recNo);
writes to the raf directly

lock:
synchronized on locks HashMap and does a lock

unlock:
synchronized on locks HashMap and unlocks the record

islocked:
synchronized on locks HashMap and returns whether it
is locked.


This is as a simple as I can get it. It ensures that only one client
may read, update, write, and delete, thus guaranteeing that only one
client can touch the raf at a time.

But the documentation states:

"Your server must be capable of handling multiple concurrent
requests."

My implementation prevents concurrent reads to the file, and thus two
people can't simultaneously pull two different records (one will have
to wait a short time).

I assume that the above quote simply means that multiple people should
be able to Book different records simultaneously, through the use of
lock, unlock, and isLocked. That is, by concurrent requests, they mean
at a higher, logical level (through locks), rather than at the file
access level.

Am I correct in this assumption? Is the implementation above okay?
[ May 15, 2005: Message edited by: Titus Barik ]
 
Uwe Schäfer
Ranch Hand
Posts: 52
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Titus Barik:

"Your server must be capable of handling multiple concurrent
requests."

I assume that the above quote simply means that multiple people should
be able to Book different records simultaneously, through the use of
lock, unlock, and isLocked. That is, by concurrent requests, they mean
at a higher, logical level (through locks), rather than at the file
access level.


i have a different assignment with comparable requirements.
i understood the issue the way you did, and i�m walking roughly the same path.
 
Muthaiah Ramanathan
Ranch Hand
Posts: 102
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
My design is as follows:

During initialization I read the records and store them in a hashtable. Any write or update or delete would actually modify the hashtable and will write the records in the file. Then for any reads - I just return the particular record, if it is not deleted. This is a simple.
 
Titus Barik
Greenhorn
Posts: 24
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Muthaiah Ram:
My design is as follows:

During initialization I read the records and store them in a hashtable. Any write or update or delete would actually modify the hashtable and will write the records in the file. Then for any reads - I just return the particular record, if it is not deleted. This is a simple.


Yes, but this introduces caching. My reasoning is that if someone wants caching, they can simply wrap the Data implementation in a DataCache decorator that they have written before using it. This also allows someone to write their own caching system on top of the given Data class.

But for this assignment, I'm not going to be bother with caching, introducing possible bugs in the process. Extra work isn't given extra points.

Thus:

DBMain data = new Data(); /* which I implement */

/* someone else can write this if they want performance
at a later time
*/
DBMain dataWithCache = new DataCache(new Data());
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic