aspose file tools*
The moose likes Developer Certification (SCJD/OCMJD) and the fly likes Question about lock() 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 "Question about lock()" Watch "Question about lock()" New topic
Author

Question about lock()

Zhou Ming M
Greenhorn

Joined: Jul 11, 2006
Posts: 1
Hi all, I have a question about the lock method, the lock() and unlock() method from my assignment as follow:

------------------------------------------------------------------------------
// Locks a record so that it can only be updated or deleted by this client.
// Returned value is a cookie that must be used when the record is unlocked,
// updated, or deleted. [b]If the specified record is already locked by a different
// client,[b] the current thread gives up the CPU and consumes no CPU cycles until
// the record is unlocked.
public long lock(int recNo) throws RecordNotFoundException;
// Releases the lock on a record. Cookie must be the cookie
// returned when the record was locked; otherwise throws SecurityException.
public void unlock(int recNo, long cookie)
throws RecordNotFoundException, SecurityException;
------------------------------------------------------------------------------

My question is that if the lock() is called with a recNo that aleady locked, how the lock() method deternmine that the record is locked by the same or different client? I have no idea since the lock() method only accept the recNo as parameter!
Jeroen T Wenting
Ranch Hand

Joined: Apr 21, 2006
Posts: 1847
Don't bother. It doesn't state what it should do if the lock attempt is made by the same client, so you can just assume it does the same thing: wait.

It's effectively impossible to determine the actual client making a request.
In practice you might do something with IP addresses a network connection is established on in some wrapper layer on top of your Data class, but that would disallow multiple clients running on the same machine.
Of you could try something with thread IDs, but that would disallow multithreaded clients.


42
Andrew Monkhouse
author and jackaroo
Marshal Commander

Joined: Mar 28, 2003
Posts: 11479
    
  94

Originally posted by Jeroen T Wenting:
It's effectively impossible to determine the actual client making a request.
Possibly a slight difference of opinion here ...

If you are trying to identify a particular client where each individual client can have multiple connections open to the server, then it can become an interesting exercise to set up a safe way to identify the client. It can be done, but you are probably going beyond the requirements.

If you are trying to identify a particular client where each individual client can only have a single connection open to the server, then it is relatively easy to do. However the potential solutions depend on the higher level networking protocol you are using: simple sockets or RMI. Alternatively if you are only exposing business methods to the client then the network protocol can be irrelevant.

So, sorry I havent given any answers, but there are not enough details to start down that path.

Regards, Andrew


The Sun Certified Java Developer Exam with J2SE 5: paper version from Amazon, PDF from Apress, Online reference: Books 24x7 Personal blog
Oliver Weikopf
Ranch Hand

Joined: Feb 17, 2004
Posts: 58
Originally posted by Jeroen T Wenting:
It's effectively impossible to determine the actual client making a request.

Not only is it possible, I believe it's a requirement. You may argue that you don't need it for lock(), but you most definitely need it for update() and delete(). You must be able to determine whether the caller owns the lock on the record it wants before you allow either of these actions.

I had first implemented it in such a way that the client could not be identified, but soon found out that this didn't meet the requirements which say clearly: "Locks a record so that it can only be updated or deleted by this client." When I noticed this, I did a search on this forum for the expression "identify client" and ended up reading about this for hours. I recommend you do the same.

This thread contains a collection of threads (it's in Andrew's first post) that may be particularly helpful.

I ended up using the "one Data instance for each client" approach and it's working fine for me.
[ July 12, 2006: Message edited by: Oliver Weikopf ]
Thirumurugan Mylrajan
Ranch Hand

Joined: Jan 26, 2006
Posts: 64
You may argue that you don't need it for lock(), but you most definitely need it for update() and delete(). You must be able to determine whether the caller owns the lock on the record it wants before you allow either of these actions.


I beleive the original poster had the cookie requirement, so I dont think there is an issue with identifying the clients. If you have the right cookie update or delete the record else wait..


I had first implemented it in such a way that the client could not be identified, but soon found out that this didn't meet the requirements which say clearly: "Locks a record so that it can only be updated or deleted by this client." When I noticed this, I did a search on this forum for the expression "identify client" and ended up reading about this for hours. I recommend you do the same.



I think if your requirement has cookies, then a single instance of data may be enough.


This thread contains a collection of threads (it's in Andrew's first post) that may be particularly helpful.


Thanks for the links, they are very informative. Why cant these be put on the FAQ so that they are not asked again and again.


SCJP , SCJD. (IBM 142 in progress).
Jeroen T Wenting
Ranch Hand

Joined: Apr 21, 2006
Posts: 1847
That's why update() and delete() take the cookie as a parameter.
A cookie can only be handed to a single client so you can safely assume (given the lack of security requirements we can assume a system without crackers) that the cookie is all the proof you need that the request is valid.

If it weren't you'd have to create an entire system with security interceptors, user credentials, and whatnot to IMO have sufficient security.
Jeroen T Wenting
Ranch Hand

Joined: Apr 21, 2006
Posts: 1847
If you are trying to identify a particular client where each individual client can have multiple connections open to the server, then it can become an interesting exercise to set up a safe way to identify the client. It can be done, but you are probably going beyond the requirements.

If you are trying to identify a particular client where each individual client can only have a single connection open to the server, then it is relatively easy to do.


I define "client" as a single instance of the client application software running somewhere.
You apparently define it as a single machine on which any number of instances of the client application software may run.

Identifying the IP address of the machine the client runs on is indeed not hard (I do that now when in networked mode, refactored the entire lock mechanism for that last night while making it more generic at the same time), identifying the client instance is indeed a lot harder (especially when using RMI, though it does look to be possible (have to give it some thought) by some sort of UID system).
Andrew Monkhouse
author and jackaroo
Marshal Commander

Joined: Mar 28, 2003
Posts: 11479
    
  94

Originally posted by Jeroen T Wenting:
I define "client" as a single instance of the client application software running somewhere.
You apparently define it as a single machine on which any number of instances of the client application software may run.
No, I have no requirements for a single machine in my definition. I was trying to limit the number of connections per client just to keep things simple, but that was my only requirement.
Originally posted by Jeroen T Wenting:
Identifying the IP address of the machine the client runs on is indeed not hard (I do that now when in networked mode, refactored the entire lock mechanism for that last night while making it more generic at the same time), ...
But that wont work if your definition of a client is just that it is running somewhere, because that definition could allow two clients from the same machine (or IP address).

Originally posted by Jeroen T Wenting:
identifying the client instance is indeed a lot harder (especially when using RMI, though it does look to be possible (have to give it some thought) by some sort of UID system).
Working with a UID will provide a reasonably reliable system, and I believe it is a very simple system to implement. But it is not necessary if you are willing to look at a Connection Factory on the server side (and, yes, I am aware that you have earlier stated that you believe that this is more complicated than is needed for the assignment. But I think it is an easy solution, and at 13 extra lines of code for the server and 1 extra line for the client, I dont think it is too much extra work).

Regards, Andrew
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: Question about lock()