• Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

B&S no lock cookies

 
Titus Barik
Greenhorn
Posts: 24
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I am doing B&S 2.3.1, my interface has the following:

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;

But since I have no clientID how can I keep track of who is locking and unlocking it? Should I simply trust the client to be honest and not worry about it?
 
Frans Janssen
Ranch Hand
Posts: 357
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
But since I have no clientID how can I keep track of who is locking and unlocking it? Should I simply trust the client to be honest and not worry about it?


Hi Titus,

You will have to figure a way to identify clients. Trusting the client will not suffice in this case, since this is one of the key challenges of your assignment.
The most straightforward way is to create a Data class instance for every client and use the Data reference as a client identifier.

Frans.
 
Titus Barik
Greenhorn
Posts: 24
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Frans Janssen:

The most straightforward way is to create a Data class instance for every client and use the Data reference as a client identifier.


Aha! I did not even considering using 'this' as the client ID. Now though, I still have a single static instance of a RandomAccessFile object, and I am not sure how to initialize it in the constructor:

private static RandomAccessFile raf;
private static final rafMutex = new Object();

public Data(File file) {
synchronized (rafMutex) {
if (raf != null) { /* set raf using file */ }
}
}

Is there a better way? I ask because rafMutex will only be used once to
initilize and validate the raf the first time.

Update: on further examination, what about synchronizing on Data.getClass()? Would there be any problems with using that?
[ May 16, 2005: Message edited by: Titus Barik ]
 
Frans Janssen
Ranch Hand
Posts: 357
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
private static RandomAccessFile raf;
private static final rafMutex = new Object();

public Data(File file) {
synchronized (rafMutex) {
if (raf != null) { /* set raf using file */ }
}
}

Is there a better way? I ask because rafMutex will only be used once to
initilize and validate the raf the first time.

Update: on further examination, what about synchronizing on Data.getClass()? Would there be any problems with using that?

You could make a new subclass of RandomAccessFile and make this a singleton (but I seem to recall you did not want to use the singleton pattern).

So if you don't want that, you could indeed synchronize on Data.getClass or you could make a synchronized static method in Data that returns the RAF reference (which would essentially be the same thing). Personally I prefer the latter because I think it's more readable.

Frans.
 
Lara McCarver
Ranch Hand
Posts: 118
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Now though, I still have a single static instance of a RandomAccessFile object, and I am not sure how to initialize it in the constructor:

private static RandomAccessFile raf;
private static final rafMutex = new Object();

public Data(File file) {
synchronized (rafMutex) {
if (raf != null) { /* set raf using file */ }
}
}


Why limit yourself to one RandomAccessFile object? Imagine that 2 threads are each calling methods in their Data objects at the same time. If there is only one RandomAccessFile object, it can only have one pointer, and when the threads swap, the location of the pointer will not go back to where it was. There was a recent discussion of this issue in this forum, and the conclusion I drew from this is that it is best to have each Data object contains its own RandomAccessFile object.

Then use the record-based lock() and unlock() mechanism to avoid having 2 threads conflicting with each other in the database. I have heard the recommendation that the list of locked records be static within the class.
 
Titus Barik
Greenhorn
Posts: 24
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Lara McCarver:

Why limit yourself to one RandomAccessFile object? Imagine that 2 threads are each calling methods in their Data objects at the same time. If there is only one RandomAccessFile object, it can only have one pointer, and when the threads swap, the location of the pointer will not go back to where it was. There was a recent discussion of this issue in this forum, and the conclusion I drew from this is that it is best to have each Data object contains its own RandomAccessFile object.


You'd have to synchronize on the raf, which effectively makes reads and writes single-threaded.

I do this because I can find nowhere in the Java standard that guarantees that you can open multiple RandomAccessFiles on the same file at once, even if you are always writing to different places. It APPEARS to work in Linux, and it APPEARS to work in Windows, but I can't find anything formally in any specification that allows this. Until I do, I consider such an implementation to be platform specific and therefore broken.

The only formal specification that I can find is on FileChannel, but that introduces NIO.
[ May 17, 2005: Message edited by: Titus Barik ]
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic