aspose file tools*
The moose likes Developer Certification (SCJD/OCMJD) and the fly likes Locking in modify method? Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of Spring in Action this week in the Spring forum!
JavaRanch » Java Forums » Certification » Developer Certification (SCJD/OCMJD)
Bookmark "Locking in modify method?" Watch "Locking in modify method?" New topic
Author

Locking in modify method?

Anonymous
Ranch Hand

Joined: Nov 22, 2008
Posts: 18944
This may sound a stupid question but I have heard that there are not such ones
So is that enough if I do locking and unlocking in Data's modify method? I think it would make client code simplier. When I use some real database I never do lockings/unlockings when I update the database. Database system takes care of it automatically.
Jukka
Stephane Weber
Ranch Hand

Joined: Mar 07, 2002
Posts: 110
Personnally, that's how I did it ...
See :

This code is the implementation of method modify in my RemoteData class of course, as no locking is needed for Data class.
Hope this helps,
Stephane
parthiban subramaniam
Ranch Hand

Joined: May 15, 2002
Posts: 116
Hi guys,
have a doubt ...
ok lets say there are 2 clients A & B a is doing a search on record 1 and so does b .. a finds 2 seats available so does b .. b go aheads and books 2 seats .. u r modify method does the lock .. modifys the record .. a still sees 2 seats avilable ... now he calls the modify after reducing the seats by 2 .. now a does not know anything abut the seats already been booked cos to him he has 2 more seats .. hmmmm does not sound right to me .. lock do a fresh search .. chk the values .. modify tht sounds gud to me ...
or am i missing something here
cheers,
parthi.


Even crazy and silly looking problems are sometimes real.
Stephane Weber
Ranch Hand

Joined: Mar 07, 2002
Posts: 110
Yes, your remark is perfectly valid. However, you can decide not to handle it differently as the assignment definition clearly states :

However, if two clients attempt to perform the sequence lock, read, modify, write, unlock concurrently, then both modification attempts will be handled correctly. The aim is to ensure that if two customers attempt to book a seat on the same flight concurrently, then the number of available seats is definitely reduced by two, unless there was only one seat, in which case, one customer will be advised at booking time that no more seats are available.

So you see, if a and b both try to book on the same flight, of course only one will have the lock at a time. When he finishes his booking, indeed there are not enough seats anymore for b to book, but the modify method could tell him so (when trying to set available seats to -2 ;-)).

Hope this helps,
Stephane
Anonymous
Ranch Hand

Joined: Nov 22, 2008
Posts: 18944
Ok, now I got the point. I think I will do the locking on client side so that the error message is easier to show.
Thank you for both of you.
Jukka
parthiban subramaniam
Ranch Hand

Joined: May 15, 2002
Posts: 116
hi,
does tht mean the logic for booking the flight tickets goes in to the modify method ??
if it does i dont think thts a good design ..
ofcourse thts my opinion ...

cheers,
parthi.
Stephane Weber
Ranch Hand

Joined: Mar 07, 2002
Posts: 110
Nope in fact after reading this post I changed a little bit my code, and indeed it is more correct the following way:
In my bookSeat method (in the RemoteData object), the sequence is :

lock(record);
read record (and throw exception if not enough seats)
modify record (and save it to file)
unlock(record);

You should not have to treat the locking mechanism yourself in the client side, it should be invisible to the client code. This way it is ...
Sorry for the confusion in my previous post ...
Hope this helps

Stephane
John Smith
Ranch Hand

Joined: Oct 08, 2001
Posts: 2937

If this is the actual code, it's very dangerous, as the unlock() may never execute. Put it in the "finally" block to guarantee the lock release no matter what happens.
Eugene.
[ September 25, 2002: Message edited by: Eugene Kononov ]
Stephane Weber
Ranch Hand

Joined: Mar 07, 2002
Posts: 110
Indeed !
Much better like this :

lock(record);
try
{
read record (and throw exception if not enough seats)
modify record (and save it to file)
}
finally
{
unlock(record);
}

Thanks Eugene
Stephane
Max Habibi
town drunk
( and author)
Sheriff

Joined: Jun 27, 2002
Posts: 4118
Be careful Stephane,
In your current implementation, you could unlock a record that you failed to lock.
Why is that a problem? Depending on your locking mechanism, Thread A could unlock a record locked by Thread b. For example, this could happen if you're not tracking the locking Thread/and or client.
If this is your approach, you should probably document the risk.

All best,
M, author
The Sun Certified Java Developer Exam with J2SE 1.4
[ September 25, 2002: Message edited by: Max Habibi ]

Java Regular Expressions
Stephane Weber
Ranch Hand

Joined: Mar 07, 2002
Posts: 110
In my implementation of lock, you can't unlock a record that you haven't locked yourself (there is client tracking associated to the lock).
However, if I am not mistaken, the code I specified in my previous post should not be a problem if 'something bad' occurs during the lock. Indeed in that case, lock throws an exception and so we don't enter the try block that could end with an unlock. We simply go to the exception handling of the bookSeat method.
Am I not right ?
Stephane
Max Habibi
town drunk
( and author)
Sheriff

Joined: Jun 27, 2002
Posts: 4118
Lock doesn't automatically throw an Exception if something 'bad' happens: It could just fail, depending on your implementation.
HTH,
M, author
The Sun Certified Java Developer Exam with J2SE 1.4
Michael Morris
Ranch Hand

Joined: Jan 30, 2002
Posts: 3451

Originally posted by Max Habibi:
Why is that a problem? Depending on your locking mechanism, Thread A could unlock a record locked by Thread b. For example, this could happen if you're not tracking the locking Thread/and or client.

That's why I had checked with the lock manager to verify that I had the lock before performing a volatile operation on the db. Here is the way I handled modify in the remote connection object:

This guarantees that I have the lock before modifying.
Michael Morris


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
Max Habibi
town drunk
( and author)
Sheriff

Joined: Jun 27, 2002
Posts: 4118
I think that's really the practical solution, which is sort of my point. I've always said that if you find yourself taking heroic measures to make your code work, then you need to reconider your design.
In this case, I think your design is on the money, hence your fairly clear code.
All best,
M, author
The Sun Certified Java Developer Exam with J2SE 1.4
Patrick Li
Greenhorn

Joined: Aug 30, 2002
Posts: 11
Here, I will try my best to make my question clear. pardon me for inappropriate terminology!
Let's assume that part of RemoteDataAccess class implemented like this:
public class RemoteDataAccess extends UnicastRemoteObject implements RemoteDataInterface, Unreferenced {
private LockManager lockManager = null;
Data db = null;
public synchronized doBooking(int record, int numberOfSeat) throws Exception {
try {
lockManager.lock (record);
db.modify(newData);
lockManager.unlock(record);
}
finally {
unlock(record);
}
}
}
My question is about double locks/release.
when a client call doBooking(), the client obtains lockManager monitor, no others can access lockManager before end of doBooking. the method lockManager.lock(int) within doBooking() is still be able to access the lockManager because Object Lock is per -thread base, not method base. but, if lockManager.lock() method call goes into wait stage for notification and release the lock on lockManager when the record is locked by another client, does doBooking() automatically release lock on lockManager while doBooking has not reach end? if doBooking doesn't release the lock on lockManager until doBooking finished which means lockManager.lock () wake up and obtains the lock on record, it means that there is only one client or connection can access lockManager at any single moment though many clients try to book different flights. and size of HashMap inside of lockManager is always one or zero. I expected that size of this HashMap will grow when a few of clients try to book different flights, because we only impose the record lock, which means modification can happen on different records concurrently without any wait. what is the relationship between lockManager.lock (record) and doBooking in term of block and release the lockManager?
Thanks,
Patrick
Michael Morris
Ranch Hand

Joined: Jan 30, 2002
Posts: 3451
Hi Patrick,

... when a client call doBooking(), the client obtains lockManager monitor

Not by the code you're showing. The client gets the monitor on RemoteDataAccess in the doBooking() method. Now you may also grab the monitor on the lockManager if the lock() method is synchronized. If each client has its own RemoteDataAccess object, there is no need to synchronize the doBooking() method. In my opinion, the lockManager object itself should control access to the map of locked records which implies that the lock() method is synchronized and contains a conditional call to wait() and unlock() is synchronized and contains an unconditional call to notifyAll().
If your locking mechanism is working properly then your map of locked records should certainly grow well beyond one item in a multi-client environment unless, you only have one RemoteDataAccess object for all clients to use. If that is the case, I would urge you to reconsider your design so that each client had its own.
Hope this helps,
Michael Morris
John Smith
Ranch Hand

Joined: Oct 08, 2001
Posts: 2937

If each client has its own RemoteDataAccess object, there is no need to synchronize the doBooking() method

In fact, it is dangerous to synchronize the doBooking() method, because you call another synchronized method from doBooking(). In effect, you sequentially obtain monitors for two objects, introducing the potential for a deadlock.
Even if RemoteDataAccess was shared by multiple clients, there would be no need to synchronize the doBooking() method, provided that this method used the locally defined or parameter-passed "newData" object.
Eugene.
Tiny Star
Greenhorn

Joined: Jul 29, 2002
Posts: 16
where shall we put the bookfilght logic ?
if we put it at client side,if something is wrong just after lock record but before unlock it
how can we unlock it for others?
(client crash problenm)
Can i put the bookfight logic at server side ?
Michael Morris
Ranch Hand

Joined: Jan 30, 2002
Posts: 3451
Hi Tiny,

where shall we put the bookfilght logic ?
if we put it at client side,if something is wrong just after lock record but before unlock it
how can we unlock it for others?
(client crash problenm)

By having the Remote connection object implement Unreferenced. If a client crashes, when RMI determines that there are no further reachable remote references it eventually calls the unreferenced() method. There is where you can release the locks owned by the client.

Can i put the bookfight logic at server side ?

You can, but there are potential consequences to doing it that way. If the network fails or the server crashes, the client has no way of knowing what the state of the booking transaction is.
Hope this helps,
Michael Morris
 
It is sorta covered in the JavaRanch Style Guide.
 
subject: Locking in modify method?