joel smither

Hi,
I'm doing the UrlyBird project and the interface provided for the Data class has methods createRecord and deleteRecord. What puzzles me is that there is NO requirement for a user to be able to run these methods.

Should I implement them?
If I need to implement them, can I assume that creating and deleting records is an off-line database maintenance activity and as a result I don't have to worry about threading. In other words there will only be 1 program accessing the database to do these operations?

What are the different possibilities for locking? I know I use synchronized methods to enusre no two threads try to update the same record at the same time...but what other choices exist?

Hi all,
I'm getting to ready to submit my work and the next step of course is to take the essay exam. Can anyone give me advice on how to prepare for that exam? I'm not sure what I should be studying......

I'm doing the UrlyBird project. Locking is an issue when the client runs in standalone mode (no networking). Locking IS an issue when I spin up multiple clients to access a single remote database file.

I'm using RMI for the networking piece. When I spin up my server, I register a remote service object in the registry which has a Data object which opens the database file and implements the methods readRecord, deleteRecord, createRecord, etc. As a result, when each client spins up, then will get a unique proxy instance that contains the remote service object registered by the server.

Since almost all of the methods in my Data class manipulate the file position indicator, I have synchronized all the methods in the class. Why? I need to ensure mutual exclusive access to the file.

I have two questions?
(1) Is this approach acceptable?
(2) Doesn't this approach ensure that multiple threads can't update the same record? I keep reading about people implementing a lock manager, but why is that needed in this approach?

Instead of synchronizing on the RAF, can't I just synchornize the methods that do a fseek, file write, file read, etc. I don't understand the difference? If the methods are synchronized that means only one method is using the file at a time right?

Also, when you say synchronize on the Hashmap, you're talking about a sunchronized block like:
synchronized(Hashmap)
{
...
}

what's the difference between using the synchronized block and having the methods in the LockManager class be synchronized. It seems they are doing the same thing...?

Thanks for the info Peter.

My Data class has the readRecord, createRecord, updateRecord methods that do the low level I/O (i.e. the seek to the proper position in the file, actual read and write, etc). Don't I need to synchronize any method that does an fseek because 2 clients could seek at the same time?

Also, with respect to the LockManager....all the methods in my LockManager class are synchronized...the methods in th class use a Hashmap to maintain information on which records are locked. The Hashmap is not a synchronzied collection, I just have a synchronized lock and unlock method in the LockManager class.

Does anyone see any problems with this approach?

I'm doing the UrlyBird project. Im my application, a factory is used to give each client a unique proxy instance that contains the remote service object registered by the server. So each client is getting their own proxy instance which has effectively wrapped the remote service object. The remote service object has a Data object that provides implementations for readRecord, deleteRecord, updateRecord, etc.... The Data class used a RandomAccessFile.

Question 1.....
In terms of threading I need to prevent concurrent updates: My Data class has a LockManager object that has a synchronized lockRecord method that locks the record. Once this is done I can update the record, then I can call my LockManager unlock method (also synchronized)to unlock the record.
This should take care of simulataneous updates right? I plan on doing the same thing for deleteRecord.

Question 2.....
Almost every method in my Data class (ie. readRecord, updateRecord, etc) manipulates the file position indicator in my RandomAccessFile (the file that actually has the data). I need to ensure mutual exclusive access to the file poisition indicator as well. Is it acceptable to make every method in my Data class synchronized? I'm not sure if this is the right thing to do or not.

Any help would be deeply appreciated.

I'm not sure if I have my queston answered or not...I'm using RMI....

Let's suppose my server has done the following:

Registry myRegistry = LocateRegistry.createRegistry
(Integer.parseInt(port));
RemoteUrlyBirdDBAccess dbServer = new DataAdapterImpl(dbpath);
String serverObjName = "//:" + port + "/" +
RMI_SERVICE_NAME;
Naming.rebind(serverObjName, dbServer);

My server binds a dbServer object to the registry. This dbServer object has a connection to the database file...it has opened the RandomAccessFile containing the database records. More specifically, the DataAdapterImpl object has an instance variable of type Data. This Data object opens the RandomAccess File and provides the readRecord, createRecord, updateRecord, etc. methods for data access.

My clients gets a remote connection from the DatabaseFactory class. The DatabaseFactory does the folloiwng:

RemoteUrlyBirdDBAccess remote =
(RemoteUrlyBirdDBAccess) Naming.lookup(lookupString);

// Transform the remote interface
DataProxy proxy = new DataProxy(remote);
return proxy;

In other words, each client gets a unique proxy instance that contains the remote service object registered by the server. So I believe that each client is getting their own proxy instance which has effectively wrapped the remote service object. So each client is using the SAME Data object correct?

Now...in terms of threading I need to prevent concurrent updates: My Data class has a LockManager object that has a synchronized lockRecord method that locks a record. Once this is done I can update the record, then I can call my LockManager unlock method (also synchronized)to unlock the record.
This should take care of simulataneous updates right?

I don't want to prevent concurrent reads do I? It seems to me that several clients should be able to read concurrently, but since I'm using a RandomAccessFile and manipulating the file pointer...I need to make sure the manipulation of the file pointer is synchronized...what do poeple do here...do the synchronize every method in the Data class, use a synchronized block for the file pointer? Not sure what to do....

Boy, the information provided on this thread is extemely enlightening, thanks for all who responded.

I want to make sure my locking is done correctly, so please forgive me if I appear to be rehashing some things...

I'm using RMI for networking. I have a Data class that implements readRecord, updateRecord, createRecord etc. Note that none of these methods are synchronized. The Data class implements my data layer so to speak. My Data class also has a LockManager. This class provides two methods, lockRecord and unlock ( which are synchronized methods).

In my client GUI, when the user wants to book a record (i.e. book a room) I first call my Data class (it has a lockRecord and unlock method as well). The lockRecord method in my Data class calls the LockManager method lockRecord to actually lock the record. Since my LockManager's lockRecord method is synchronized, only 1 client at a time can lock a record. Once I have the lock I call the updateRecord method in my Data class to update the record. Then I call my LockManager's unlock method to unlock the record. Doesn't this sequence of events ensure mutual exclusive access to that record? There's no way that 2 clients could update the same record with this scheme is there?

My second question is this: on a previous reply it was mentioned that I need to ensure access to my RandomAccessFile properly. In other words, one client could seek to record 5 while another could seek to record 10....all hell could break loose then...one client actually gets record 10 expecting record 5...

When I implemented the methods in my Data class, my filePointer variable is initialized once at start up (when I first open the file I read all the records in it and set the file pointer) and never modified again. From that point on the file pointer is just used as an offset to the appropriate record. So I'm thinking that my methods to fetch records are essentially thread safe. Is this correct or am I all screwed up here?


Also, Sun has instruction that state that I can;t change the DBAccess interface that the Data class implements, doesn;t this mean I can't add the synchronized keyword to those methods?

I think I understand what you're saying, however I still don't think I need to make any method synchronized except for lockRecord and unlock methods defined in my LockManager class.

My Data class is used in local mode as well as remote mode to manipulate the records in the database. My Data class has an instance variable that is an instance of the LockManager class. When my GUI client needs to update a record, the first thing I do is lock the record (this is a synchronized method). Once the record is locked, I can update it, there is no need for this method to be synchronized is there? I then go ahead and update the record, then call the lock method (another synchronized method). Is this OK?

In the UrlyBird project there is no requirement for the end user to do a delete, as a result I've assummed this is an off-line operation that doesn't need to be synchronized.

Whenever I want to book a record (i.e. update the record) I perform a lock on it....it's the lock method in my LockManager class that is synchronized...so I still don;t understand why the update method needs to be synchronized. You have to have a lock on the record before you can update it.

I'm sort of weak on terminology. I believe my Data class is a facade...it is the class that implements the methods readRecord, createRecord, deleteRecord, updateRecord, lockRecord and unlock, etc. The lockRecord and unlock methods are not synchronized in this class. So is this what u mean by facade?

My LockManager sychronizes its methods called lock and unlock. When I want to update a record, I first call the lock method in my LockManager class. Once I get the lock I then call updateRecord to actually update the record.
Why do the updateRecord and deleteRecord methods have to be synchronized in my Data class?

Hi I'm working the UrlyBird developer project. I have implemented a seperate LockManager class to to the real work of locking and unlocking records. I have made these methods synchronized, because they need mutual exclusive access to some hashmaps I'm using to maintain information on which records are locked.

Is there really a need for nay other methods to be synchronized? In my Data class I have methods readRecord, updateRecord, findByCriteria, etc. These methods don't have to be synchronized do they?

I'm really having trouble with record locking on the urlybird project. I'm using RMI. I have a local interface called UrlyBirdDBAccess and a remote interface called RemoteUrlyBirdDBAccess. I have a factory that returns either a local connection (object that implements UrlyBirdDBAccess) or a remote one through RMI (object that implements RemoteUrlyBirdDBAccess), however I use an adapter to transform the object that implements the RemoteUrlyBirdDBAccess interface to an object that implements the UrlyBirdDBAccess interface so the client doesn't need to know the difference between the actual connections.

When I run in a standalone mode (i.e. local connection), the lock and unlock methods implemented in the UrlyBirdDBAccess do nothing...record locking is not an issue in standalone mode.

I'm having trouble implementing the lock and unlock methods for the RemoteUrlyBirdDBAccess interface. On the remote side, do I need to call the methods lock and unlock defined in the UrlyBirdDBAccess interface or is
it ok to just ignore them in terms of implementing the lock and unlock methods declared in RemoteUrlyBirdDBAccess.

Hi all, I'm been reading Trottier's book "Java 2 Developer - Exam Cram 2".
I've stumbled across some links on the net that state that there are some errors in his locking code (specifically in his implementation of the LockManager) class.


Can anybody be more specific about what those errors are so I can correct the mistakes. I've been unable to find a web-site that has any corrections.

Thanks in advance.