This report shows the total number of points awarded for each section. The maximum number of points is 400, to pass you need a score of 320.
General Con: 100 90
Documentation: 70 70
OOD: 30 30
GUI: 40 26
Locking: 80 80
Data Store: 40 40
Network Server: 40 30
Total: 400 366
I did not know rmiregistry can be launched programmatically by calling LocateRegistry.createRegistry(). So in the user guide I asked user to open a DOS window and start rmiregistry manually.
Andrew, please feel free to let me know or even modify/delete my post if I talked too much and violated the policy of this forum.
The first thing to implement locking is to identify clients. (It is connections in my case. I allowed multiple connections even if from a single client. Of course, I documented my design and explained why.)
The DBMain interface does not carry any info about who is the client sending the request. You need to figure out a way to pass client identity through it. And your design should fit both remote and local databases.
The second thing is to mark a record as locked or not. With this mark you can tell whether a record is locked and use it to prevent other clients operating on it. For example, a locked record can not be updated and deleted by other clients.
The last thing is to add client identity into the mark of lock. You need this info to tell who is the owner of the lock, and only the owner can release the lock.
All above is about the minimal requirements. In practice, a client can lock a record and hold it for a while. Your solution should allow other clients to read the record during this period. That means you need handle the conflicts between read and write accesses besides the lock which only good for the conflicts between write and write accesses. (I designed an additional short-term lock to handle that. It can be shared among read accesses and grant a higher priority to write access. Any way, this additional lock is not visible to clients.)
Hope it helps.
We typically only allow very small amounts of code to be posted. We certainly do not allow posting of more than one method in any area where there are major points awarded.
However talking about the concepts is allowed, as is psuedo-code (as long as it is properly abstracted). We even allow large amounts of code to be posted if it is not directly related to the assignment (for example, you could post an entire locking solution as long as it cannot be used in the real assignments without the reader making major modifications after understanding the concepts). Those last two can be quite hard to write after you have working code though. Usually it is easiest to just talk about concepts as you have been doing - that is also safest.
Originally posted by Ed Tse:
Posting source code is not allowed.
Please elaborate on "The DBMain interface does not carry any info about who is the client sending the request. You need to figure out a way to pass client identity through it. And your design should fit both remote and local databases."
1) public String read(int recNo) throws RecordNotFoundException;
2) public String read(Object clientID, int recNo) throws RecordNotFoundException;
The 1) is from DBMain and the 2) is just an example. Obviously the 1) does not carry client info.
The point is that how to pass additional info/data through an interface. Changing interface as shown above is one of the ways.
// Locks a record so that it can only be updated or deleted by this client.
// If the specified record is already locked, the current thread gives up
// the CPU and consumes no CPU cycles until the record is unlocked.
public void lock(int recNo) throws RecordNotFoundException;
then all I can solve the lock problem is by using
public void delete(int recNo) throws RecordNotFoundException;
Next I have read the posts about the lock mechanism. Here is how I have solved it, please comment.
As I see it I'm the developer and I decided that all calls to Data(and the db-file) shall be done through my business class called DatabaseClient. Both the network and non-network db-access is done through this class.
And to ensure that all instances of DatabaseClient works on the same Data my class Data implements the singleton pattern.
So when the user request either delete or update the DatabaseClient first locks the record, performs the task and unlocks it. Since they all work on the same instance of Data I ensure that only the client that locked the record can update/delete it.
It is normally considered bad etiquette to hijack somebody else's thread. This thread should stick to Xiao's topic(s) - talking about passing SCJD and passing along hints.