• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

Question about lock()

 
Greenhorn
Posts: 1
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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!
 
Ranch Hand
Posts: 1847
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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.
 
author and jackaroo
Posts: 12200
280
Mac IntelliJ IDE Firefox Browser Oracle C++ Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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
 
Ranch Hand
Posts: 58
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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 ]
 
Ranch Hand
Posts: 64
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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.
 
Jeroen T Wenting
Ranch Hand
Posts: 1847
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
Posts: 1847
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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
Posts: 12200
280
Mac IntelliJ IDE Firefox Browser Oracle C++ Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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
 
reply
    Bookmark Topic Watch Topic
  • New Topic