About cookie lock Andrew�s solution..

[Tiago Prestes]

Hi all,

I have a problem. In my assigment (URLyBir 1.3.1) the lock method don�t have the cookie parameter. So I don�t know how I do to know wich client locked the register.
In Andrew�s book, the solution is good but is passed by parameter to method lock().
I asm thinking that: I will implement the lock method in DataClass and in DataClassRemote, but just in dataclassremote the lock will be used. So, in DataClassRemote I will implement the method lock with the cookie parameter, and then I used the Andrew�s book solution.
Andrew, and all, what do you think about this??

Thanks in advance.

[Rob Cromley]

Verify that you're supposed to have a lock cookie passed in. I haven't heard about that way before. In every other SCJD assignment I've heard of the lock method takes a parameter of recNo (record number) and returns the lock cookie.

[Mihai Radulescu]

Hi guys,

I also don't have cookies -I use some candy bar instead , not all solution requires cookies and in this case you must thin on a way to identify your clients, a good way to do this is to use a Data Access Object per client and to use this like client id. This soltion look like this :

client 1 - data access (for client 1) - \
                                         server 
client 2 - data access (for client 2)-  /

Regards M
[ March 23, 2007: Message edited by: Mihai Radulescu ]

[Andrew Monkhouse]

Hi Tiago,

Originally posted by Tiago Prestes:
In Andrew�s book, the solution is good but is passed by parameter to method lock().

I don't understand what you are asking about here. We didn't use cookies in our solution. Did you have a question about what we were doing? (always remembering we deliberately wrote our assignment so that the code could not be used directly in the Sun assignment).

Originally posted by Tiago Prestes:
I have a problem. In my assigment (URLyBir 1.3.1) the lock method don�t have the cookie parameter. So I don�t know how I do to know wich client locked the register.

Did you look at the discussion in "Discussion Point: Identifying the Owner of the Lock"? In my copy of the book, this is pages 150 - 154. Do any of those potential solutions help? Or would you like to discuss them further?

Regards, Andrew

P.S. My internet access has been very limited for the last 2 weeks and will not improve for 2 weeks (I have been quoted - it may well be longer). So I will try to drop into this topic again, but I cannot make promises.

[Lucy Hummel]

Hi Tiago,

In my case the server does not have to identify the client.

That is why I did not studied the issue you want to discuss.

Br, Lucy

[Ravikiran Vishnuvajhala]

I feel in this case, we can go with the solution that Andrew defined in his book i.e using something like the ReservationManager to maintain the log of owners of locks using the Database instances.

Andrew,

If we go with the similar solution as your ReservationManager, won't there be a problem when multiple threads (not using RMI or sockets or Swing, but using plain java classes) access the lock/unlock methods of a single Data class's instance? Or do you think we can safely assume that each thread should create a separate instance of the Data class based on this statement -

"You may assume that at any moment, at most one program is accessing the database file; therefore your locking system only needs to be concerned with multiple concurrent clients of your server."

I think this problem will not arise from the remote server as we are creating a separate instance for each client.

Thanks
Ravi

[Andrew Monkhouse]

Hi Ravi,

That quote you provide from the instructions pretty much covers your concerns

Since only one program can ever be accessing the database file, as long as your server is running then no other application will be able to access the database unless they are going through your server - and therefore using your locking solution.

When you create your locking solution, you will (of course) be documenting it properly in JavaDoc and potentially in the associated readme files (or whatever you are allowed to include (such as design decision documents)). So you can describe any requirements that your locking solution might have (such as client identification requirements) and describe why you went that way.

Regards, Andrew

[Arno Reper]

such as client identification requirements

DO you mean we might ask the user for an id or something? in my assignment, i need cookie to identify who has a lock on a record...it would be nice that i could ask the use rto insert his (fake) id number
Thanks for your answer,
Arno

[Andrew Monkhouse]

Originally posted by Arno Reper:
DO you mean we might ask the user for an id or something?

That wasn't my meaning, but it is a possibility.

In a real business environment, we could have the CSR enter their User ID when they start their application, which could then be passed into the Data class' constructor, and then used as a the cookie from that point onwards. It would have the added benefit of making the log files much more useful. You might also consider doing some extra magic on this ID (such as multiply the CSR's User ID by 100, then allowing them to have 100 instances of the application open).

However this is all way beyond the scope of the assignment. And there is a specific statement in the instructions telling you that you will not get extra marks for going beyond the requirements.

So you cannot improve your mark by doing this.

But get it wrong, and you could easily loose marks for doing this.




As for what I did mean: if Ravi's solution requires each client to have an instance of the Data class for identification purposes, then that should be indicated in the Javadoc documentation and in the design decisions documentation.

Regards, Andrew

[Arno Reper]

Thanks for your answer Andrew,
What kind of cookie should I use then? Something autogenerated by my "lockmanager" and transmitted to the owner of the lock?
Arno