David Winters Junior

Ranch Hand
+ Follow
since Oct 30, 2007
Merit badge: grant badges
For More
Cows and Likes
Cows
Total received
In last 30 days
0
Forums and Threads

Recent posts by David Winters Junior

Kah,

yes i agree after reviewing the application it would make send to use the update() method on book rather than the delete() method so avoiding this whole issue.

Thanks for the reply
david
All,

Just a quick query in my urlybird application i must reuse deleted records as specified by the sun interface delete() method below. The delete method is called when i book record whereby i write the customer id field along with the booked record and i change the delete flag from 0 to 1 making it unavailable. So the question is if i delete the record from the database file along with the customer booking reference how can i view existing records already booked in the ui. My application does not require this but this is simple functionality.
Also if i do reuse existing space for deleted records how does the application record which customer booked a particular room?

Sun interface comment
Deletes a record, making the record number and associated disk storage available for reuse.

Thanks
David
Alex,

OK thanks for the clarification that makes sense.

I have the lock/unlock methods defined in my facade class used to call methods in Data.java(implements DBMain interface provided by Sun) as is defined in the interface provided by Sun. I then call LockManager's methods from wtihin these methods to perform the actual details of these methods. Just reconfirming this is okay?

David
Hi Ivan,

Not sure what you mena by copying and pasting the javadocs here?

Can someone comment on this, we should be able to follow this design as long as we comment on this in our design document?

Surely someone on the forum can comment on this issue?

David
All,

I have quick question, my Data class implements the Sun interface specification DBMain.java however in the lock() and unlock() methods i do not provide any details within these methods. I use a LockManager class to encapsulate the reserving/releasing of records.This class is then used by a facade class which call methods within the LockManager class to do the locking/unlocking of records. Is this okay to do once it is documented or will it be an automatic fail if i do this.

Also in the interface specification, unlock() and unlock() methods throw a RecordNotFoundException,is it okay to call further exceptions from these methods within my LockManager class or should i adhere to the method declaration with the interface specification.

Your comments would be most appreciated.

David
Hey,

yes i see no reason why one could not do this as long as the methods are related to the functionality of the Data class and not functionality which should be delegated to another class. What will these new methods do exactly?
david
Hi,

I have doen this design of having two caches one for the deleted records and one for the actual records in a database file. Accessing the database directly is not a good idea in my opinion, having a cache improves performance although i can see the alternate argument also that if the cache grows this will take up memory but memory should not be an issue on the hosted server these days.

Just my opinion anyways
All,

Just wondering in the lock method is it really necessary to check which client
owned the lock?

In my lock method i have created a lock per record so that only client waiting for that specific lock will be notified. Ive seen other also in their lock methods check whether the previous lock owner had the lock prior to granting the lock to the owner again so in this way the same client cn't have access to the same lock twice in a row...

So my question is if the lock owner can't have the same lock again in succession then what action do we take, how do i prevent this owner from getting access to the lock?
what have others done here?

Thanks,
david
All,

I have decided to adapt a locking solution as follows:

I have a seperate LockManager class to handle locking records so that only one
client can modify a record at one time.

In my Lock method i use a solution similar to Andrew MonkHouse whereby each client wanting to modiy a record will wait for a specific condition to be triggered.

i include here andrew's code from his book for the reserve lock method



I have completed the following code for the release lock counterpart of this method in the lock manager class and it works okay with the tests i have completed.

I am looking for some feedback here on what one thinks of this code, is their any issues with it as far as one can see:



Your input would be appreciated

David
Roman,

I have a log file for each class in the project so that if an exception occurs then i log it to the log file and the in the catch block throw the exception. You should define verious exceptions at each layer, the server layer, gui layer of the application etc.

So in order to have a log file for each class - i created a Logger class which will be instantiated when each class is instantiated. It is good for debugging
and is closer to a real world solution for logging here.

I hope this helps
David
Roman,

Agreed since the locking is on the server side if the client crashes then it does not matter the record will be booked or updated as needed anyway and the lock will be released either way here, it is not necessary to do this but more importantly it is very risky since another client may be modifying the same record and releasing the lock would lead to data integrity issues here.

Thanks,
David
Hi Guys,

I am trying to figure out how i can use the Unreferenced interface to release a lock a client has if the client should crash unexpectedly.

I have implemented the locking in a seperate Lock managaer class and the locking is implemented on the server side in a pattern similar to lock(recno)-> dooperation(recno)->unlock(). Although the chance of the lock remaining even if the client crashes is small it still is possible.

Now i have decided to implement the Unreferenced interface on the Remote server object- each client will have its own unique instance of the remote object (this is how we identify the client that owns the lock).

Now the method unreferenced() will be called by the server on each client stub which is stale or which may have crashed however i would like to implement in here some logic which would release the client lock from a hashtable which stores the client which holds the lock on a record should the client crash.
However i am not sure how i can do this? how can i uniquely identify the client to allow me to release its lock from the hashtable inside the unreferenced() method.

Perhaps others have used this interface in a different way to achieve the same objective here...

I have read a number of other posts on this issue and there is no definitive answer on the issue.


Any help would be appreciated
david
Hi,

Well yes of course, if the data in the file is in anyway bad or the wrong data is contained in the .db file then the whole application will fail so yes it should be verified and checked in some way.

Thanks,
david