My personal opinion it is a design which will can lead to get max scores, but which can lead you to fail.
If a user has locked a record, but has not started updating it, another user should be able to read the record, which is not possible in your implementation.
The Interface says:
// Locks a record so that it can only be updated or deleted by this client.
It says nothing about read, find, create methods.
Is it said "I can only implement the lock/unlock methods for the update and delete method,another methods ignore that."?
private static int DATABASE_LOCK=-1;
Should be declared as "private static final int".
public void lock(int recNo) throws RecordNotFoundException {
Integer recordNumber = new Integer(recNo);
synchronized (mapLocks) {
Synchronize the entire method, instead of the block, -- it will be much more readable and 99.99% of the time spent in your method is spent in the synchronized block anyway.
catch (InterruptedException e) {
throw new RecordNotFoundException(UNEXPECTED+":Interrupt ocurred. Could not complete lock.");
}
This is bad. You are mapping the InterruptedException into a RecordNotFoundException, which is misleading to the caller of the method.
mapLocks.put(recordNumber, this);
Which object is pointed to by "this"? You said that your methods are part of Data, so "this" must be an instance of Data?
while (mapLocks.get(recordNumber) != null && mapLocks.get((recordNumber).equals(this)
There is no reason to call mapLocks.get(recordNumber) twice. Also the while loop is misleading here, -- you are not iterating and you are not waiting on a condition. A simple "if" will do it.
Your data access class must be called "Data.java", must be in a package called "suncertify.db", and must implement the following interface:
package suncertify.db;
public interface DBMain {
// Reads a record from the file. Returns an array where each
// element is a record value.
public String [] read(int recNo) throws RecordNotFoundException;
// Modifies the fields of a record. The new value for field n
// appears in data[n].
public void update(int recNo, String [] data)
throws RecordNotFoundException;
// Deletes a record, making the record number and associated disk
// storage available for reuse.
public void delete(int recNo) throws RecordNotFoundException;
// Returns an array of record numbers that match the specified
// criteria. Field n in the database file is described by
// criteria[n]. A null value in criteria[n] matches any field
// value. A non-null value in criteria[n] matches any field
// value that begins with criteria[n]. (For example, "Fred"
// matches "Fred" or "Freddy".)
public int [] find(String [] criteria)
throws RecordNotFoundException;
// Creates a new record in the database (possibly reusing a
// deleted entry). Inserts the given data, and returns the record
// number of the new record.
public int create(String [] data) throws DuplicateKeyException;
// 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;
// Releases the lock on a record.
public void unlock(int recNo) throws RecordNotFoundException;
// Determines if a record is currenly locked. Returns true if the
// record is locked, false otherwise.
public boolean isLocked(int recNo)
throws RecordNotFoundException;
}
Any unimplemented exceptions in this interface must all be created as member classes of the suncertify.db package. Each must have a zero argument constructor and a second constructor that takes a String that serves as the exception's description.
Any methods that throw RecordNotFoundException should do so if a specified record does not exist or is marked as deleted in the database file.
Your server must be capable of handling multiple concurrent requests, and as part of this capability, must provide locking functionality as specified in the interface provided above. 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. Any attempt to lock a resource that is already locked should cause the current thread to give up the CPU, consuming no CPU cycles until the desired resource becomes available.
This is bad. You are mapping the InterruptedException into a RecordNotFoundException, which is misleading to the caller of the method.
// 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.
For the unlock, you need to know that you own the lock, and if so, you need to unlock it. Even if this thread was sliced out after the if statement was evaluated as true and before the resulting actions take place, nothing will have changed - no-one else could have removed your lock. Maybe coding a while statement will be better for future enhancements (I cant see how in context), but my personal feeling is that the if statement is slightly more readable in this case.
method-chain like this: find-->read-->update
The Sun Certified Java Developer Exam with J2SE 5: paper version from Amazon, PDF from Apress, Online reference: Books 24x7 Personal blog
Since you are storing "this" instance of the Data class in your lock, you are correct to have a separate synchronized block on the static map. You cannot synchronize on the entire method.
In other words,you agree to separate synchronized block on the static HashMap?So,My coding like this is OK?
The Sun Certified Java Developer Exam with J2SE 5: paper version from Amazon, PDF from Apress, Online reference: Books 24x7 Personal blog
The Sun Certified Java Developer Exam with J2SE 5: paper version from Amazon, PDF from Apress, Online reference: Books 24x7 Personal blog
I assume that the code you posted was just to give an indication of what you intend to do - it is nowhere near complete code.
As such, you have got the basic calls correct, now all you need is to flesh it out.
so,this locking chain like this:lock-read-update-unlock
.So is currentThread a proper identification of the client holding the lock
The Sun Certified Java Developer Exam with J2SE 5: paper version from Amazon, PDF from Apress, Online reference: Books 24x7 Personal blog
I have a knack for fixing things like this ... um ... sorry ... here is a consilitory tiny ad:
Gift giving made easy with the permaculture playing cards
https://coderanch.com/t/777758/Gift-giving-easy-permaculture-playing
|