Win a copy of The Little Book of Impediments (e-book only) this week in the Agile and Other Processes forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

URLyBird: Locking a record twice

 
Henrik Strand
Greenhorn
Posts: 20
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi all!

What happens in your implementation when the Data clas caller calls lock() twice on the same record? Is it ok if the client locks itself since its very stupid of the client to call lock twice, or should the Data implementation handle this use case?

Regards,
Henrik
[ February 09, 2006: Message edited by: Henrik Strand ]
 
B Chen
Ranch Hand
Posts: 89
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
You will deadlock, unless you can some how tell its the same client trying to lock the same record twice.
[ February 10, 2006: Message edited by: B Chen ]
 
Kevin Conaway
Ranch Hand
Posts: 57
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Henrik,

What you want is something called a reentrant lock. Basically it can keep track of who has locked it and how many times they have locked it. If you are already keeping track of who has a lock, implementing a counter shouldn't be much harder.

Kevin
 
B Chen
Ranch Hand
Posts: 89
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I just looked at my assignment again and I noticed, "If the specified record is already locked by a different client, the current thread..."
Looks like I got more work to do. And I thought I was finished with this part of the assignment.
[ February 10, 2006: Message edited by: B Chen ]
 
Yupp Cook
Ranch Hand
Posts: 49
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hello

How can you prove inside the lock method if it might be locked already by the same user? What kind of user info is there inside

public long lock(int recNo) throws RecordNotFoundException?

It could be checked comparing the cookies, but no cookies is passed to the lock method.
 
B Chen
Ranch Hand
Posts: 89
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Without user information, about the only thing you can use is the thread reference. Not bad to implement for sockets, but a bit harder for RMI.
 
Andrew Monkhouse
author and jackaroo
Marshal Commander
Pie
Posts: 12014
220
C++ Firefox Browser IntelliJ IDE Java Mac Oracle
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi B & Yupp,
Without user information, about the only thing you can use is the thread reference. Not bad to implement for sockets, but a bit harder for RMI.
You can't use the thread reference in RMI unless both calls to the lock method are called from the same remote method (that is, within the server you call lock() twice) - and why would you do that? If your client is calling the lock methods, then it is quite possible that a different thread will be used for each remote method invocation, and this stops you from using the thread reference.

If you create a connection factory on the server, such that each client gets it's own connection object, then you can use that object to track ownership of locks, and as an added bonus you would be able to use the Unreferenced interface to get notification of when clients crash, and release their locks. Doing this kind of makes the whole lock cookie redundant though .

Regards, Andrew
 
Yupp Cook
Ranch Hand
Posts: 49
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi all!
I think to keep things easy and maintainable the best is not to handle this special case at all. If the client locks twice the same record it's his fault. Too bad - stuck there forever! Everybody agrees?

[ February 11, 2006: Message edited by: Yupp Cook ]
[ February 11, 2006: Message edited by: Yupp Cook ]
 
Henrik Strand
Greenhorn
Posts: 20
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Exactly! This is the meaning with my question!

The spec. does not say anything about this issue. One could argue that we need to implement this to make the server more secure, but could also argue that we shouldn't because it's not in the spec and we will not receive any more credits for doing it.

Comments?

Regards,
Henrik
 
B Chen
Ranch Hand
Posts: 89
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I am beginning to realize this myself.
Either design the server to be more secure (extra "bells and whistles"), or design the client to avoid deadlock problems (which would also make the client simplier). Simplier is usually the way to go with the assignment, as long as the stated requirements are meet. Looks like I will be spending more time on the choices.txt file explaining my decision instead.
[ February 11, 2006: Message edited by: B Chen ]
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic