The Sun Certified Java Developer Exam with J2SE 5: paper version from Amazon, PDF from Apress, Online reference: Books 24x7 Personal blog
Any intelligent fool can make things bigger, more complex, and more violent. It takes a touch of genius - and a lot of courage - to move in the opposite direction. - Ernst F. Schumacher
If the database was locked in order to perform an addition to the database or some other major change, then when the change is complete, then the clients will start aquiring locks again.
I am not sure about the following bit of code:
if ((isDbLocked) && (dbLockingClient != this))
I think your two variables are essentially duplicating each other, so you could reduce this to:
if ((dbLockingClient != null) && (dbLockingClient != this))
Are you maintaining a Map or Set which corresponds directly to the database? So you have one item in the map or set for every record in the database regardless of whether the record is locked or not? This implies that you have to add records to the map / set if a client calls the add() method. I just added and removed items from my set on the fly as clients called lock and unlock. So if someone locked record 5, I would add Integer(5) to my set. If it exists in the set then the record is locked. When they unlock it, I just remove that Integer. Doing it this way means that locking the database becomes just another add to the set where I am adding Integer(-1).
Remember that your locking does not have to be bullet proof. I would advise that you choose one scheme or the other, either keep a static boolean to indicate the state of the db lock or recursively lock each record and just allow every thing else to flow as normal and don't worry about clients in the wait pool.
Actually my lock & unlock are done by a lock manager class which has a Hash map to keep track of who locked which record etc.
Any intelligent fool can make things bigger, more complex, and more violent. It takes a touch of genius - and a lot of courage - to move in the opposite direction. - Ernst F. Schumacher
Originally posted by shan chen:
Hi, padmaja,
Do we really need to keep the id who locked the record? I think it is not necessary. Andrew mentioned set. I know someone used vector. These are simple and good enough.
Any intelligent fool can make things bigger, more complex, and more violent. It takes a touch of genius - and a lot of courage - to move in the opposite direction. - Ernst F. Schumacher
The Sun Certified Java Developer Exam with J2SE 5: paper version from Amazon, PDF from Apress, Online reference: Books 24x7 Personal blog
Originally posted by Andrew Monkhouse:
Hi Padmaja,
Padmaja, the way you are doing it is fine, and many others also do this.
Just to give you an alternate to think about though, I have put the lock owner verification right at the RMI Interface. In my case, the Data class is only concerned with whether the record is locked, not who locked it. The RMI interface keeps track of which records were locked by this connection and simply ignore any attempt to unlock a record that this connection did not lock.
The disadvantage is that I am now tracking locks in two different places: in the RMI code and in the Data class.
The advantages are:when unreferenced gets called, the RMI code knows explicitly which locks it has to unlock the mechanism for identifying who the owner of the lock is, is kept away from the Data class. If you have the Data class track this, then you either have to use the thread to track the user, or you have to change the signature of lock method. If another networking solution was added that didnt really work well with having a thread dedicated to each connection (say MQ), then you would have to try and force it to work with threads in your case - in mine, I just have to work out what does work with the new networking solution, and keep it in the networking code
Regards, Andrew
Any intelligent fool can make things bigger, more complex, and more violent. It takes a touch of genius - and a lot of courage - to move in the opposite direction. - Ernst F. Schumacher
Any intelligent fool can make things bigger, more complex, and more violent. It takes a touch of genius - and a lot of courage - to move in the opposite direction. - Ernst F. Schumacher
Just think about the threading problems and chaos you would have if every client interacted with the same remote object.
That remote object should have a method like getConnection() which will return a unique DataAccess (or whatever you call it) object to the calling client.
Andrew The RMI interface keeps track of which records were locked by this connection
Shan Do you also imply one remote object for each client?
Michael Once again, I can't speak for Andrew, but I would guess that is exactly what he means. The Factory pattern for RMI applications is very common.
Shan According to RMI policy, the DataAccess object passed to client is pass-by-value. In the case that the client want to call 'book', will the client call DataAccess directly or through the remote object?
The Sun Certified Java Developer Exam with J2SE 5: paper version from Amazon, PDF from Apress, Online reference: Books 24x7 Personal blog
Consider Paul's rocket mass heater. |