• Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

NX: URLyBird locking question

 
Min Huang
Ranch Hand
Posts: 100
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi all,
I am a bit confused about the locking portion of the exam. My assignment file says this:
"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."
If that's the case, why do I have to lock individual records? It would be useful if I have multiple threads working on the file all at the same time, as long as none of them worked on the same record, but from my understanding of that passage, only one should be working on the db file.
Also, the public interface DB that Sun provides seems to be the interface clients will use when working with the database. It has lock/unlock methods, which strikes me as odd, because I would think locking/unlocking should be done by the server (in case, say the client disconnects or something before unlocking)? So, who does it? Client or server?
Now I'm horribly befuddled. Can somebody help?
 
Nathaniel Stoddard
Ranch Hand
Posts: 1258
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi all,
I am a bit confused about the locking portion of the exam. My assignment file says this:
"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."

This is saying that only one PROGRAM is accessing the actual database file. There's no need to lock the file as you read/write from/to it, as this is somewhat an OS issue and I assume the graders don't want to deal with it. If this wasn't the case, then you would have to do all kinds of crazy things to make sure that things you write to it are actually committed in a valid fashion.

If that's the case, why do I have to lock individual records? It would be useful if I have multiple threads working on the file all at the same time, as long as none of them worked on the same record, but from my understanding of that passage, only one should be working on the db file.

You will need to have multiple threads accessing your server portion. This doesn't contradict the previous point of only one program accessing the database file (your program!).

Also, the public interface DB that Sun provides seems to be the interface clients will use when working with the database. It has lock/unlock methods, which strikes me as odd, because I would think locking/unlocking should be done by the server (in case, say the client disconnects or something before unlocking)? So, who does it? Client or server?

This is an ongoing debate: should I use a 2-tier or 3-tier approach? This is just one of the decisions you need to make. It sounds like you're going for a 3-tier approach. So did I.

Now I'm horribly befuddled. Can somebody help?

Yes.
 
Vishwa Kumba
Ranch Hand
Posts: 1066
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
The application is a client-server application. The server should be capable of serving multiple clients at the same time.
1. Locking of the individual record is required so that only 1 client is updating/deleting a particular record at a time. Other clients wanting to update/delete the same particular record have to wait for the first client
to finish with that record.

2. Locking at the file is always required, so multiple clients writing to the file at the same time do not corrupt the database, especially if your design uses a single shared file writer object.(RandomAccessFile)

In my instructions it says......
The company's IT department has a data file that contains the essential information for the company, but because the data must continue to be manipulated for reports using another custom-written application,
the new system must reimplement the database code from scratch without altering the data file format.

What the above instructions and your quoted instructions mean is that:
There could be other systems apart from our application reading/writing to this database file. But we do not have worry much about that. We need to be concerned only about the concurrency issues caused by our multiple clients accessing/trying to update the database at the same.
Cheers,
Vish (SCJD in progress)
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic