• Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

URLyBird: Question about update e delete methods

 
Alexandre Baldo
Ranch Hand
Posts: 48
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hello, guys!

These methods are declared as:



Before calling 'deleteRecord' or 'updateRecord' I call 'lockRecord' to logically lock the record and get the cookie. I have to pass the cookie to these methods.
When 'deleteRecord' or 'updateRecord' is done I call 'unlockRecord' to release the lock.



My question is:

Why do I need to pass the cookie to deleteRecord/updateRecord ??? I don't know what I have to do with it inside these methods...

Thanks!!
 
Roberto Perillo
Bartender
Posts: 2271
3
Eclipse IDE Java Spring
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
This cookie (the long value) is used just to identify the client that locked the record that is about to be updated/deleted. When you lock a record, you have to somehow associate its number with this cookie (you can use a Map<Long, Long>, for instance, where the record number is the key, and the cookie is the value). In your update/delete methods, you just verify if the cookie that is being used to update/delete a particular record is the same one that you returned to the user when that record was locked. You're in the right path, you just have to add this verification to your update/delete methods and you're fine!
 
Alexandre Baldo
Ranch Hand
Posts: 48
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Got it!

Thank you, Roberto!
 
Naveen Hegde
Greenhorn
Posts: 17
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
i think we can use either a 'cookie' or 'sessionId'. cookie is more of web application buzzword. i believe for a client application like one in the assignment, 'sessionId' makes more sense.
i plan to design like this:
1. create a unique sessionId for each client - may be based on clientIP,login time etc. It will remain unchanged till the client logs out/exited.
2. maintain a map like : RecordLockMap<RecNo:sessionId> in the DataAcces class
3. Use this id to find out current owner client for a given record.
This way, we can avoid generating the cookie for each request and keeping it updated both at client side and server side.
In summary, using a sessionId is one time effort and easy to implement. using cookie adds more complexity into the code.
any comments?
 
Roberto Perillo
Bartender
Posts: 2271
3
Eclipse IDE Java Spring
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
As long as it is a long value (if the lock method returns a long value) the uniquely identifies the client, it's fine.
 
Rajesh Moorthy
Ranch Hand
Posts: 30
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi,

This cookie (the long value) is used just to identify the client that locked the record that is about to be updated/deleted. When you lock a record, you have to somehow associate its number with this cookie (you can use a Map<Long, Long>, for instance, where the record number is the key, and the cookie is the value). In your update/delete methods, you just verify if the cookie that is being used to update/delete a particular record is the same one that you returned to the user when that record was locked. You're in the right path, you just have to add this verification to your update/delete methods and you're fine!


Please refer the statement in bold above.

Accordingly I do the following for update/delete record:

1) Lock Record and obtain the cookie
2) Pass the Cookie to update/delete method.
3) Here in the update/delete method, I do not already have a value to compare it against the cookie. How should the comparison be done?
4) Unlock record.

Thanks & regards,
Rajesh.


 
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
Roberto Perillo wrote:This cookie (the long value) is used just to identify the client that locked the record that is about to be updated/deleted. When you lock a record, you have to somehow associate its number with this cookie (you can use a Map<Long, Long>, for instance, where the record number is the key, and the cookie is the value). In your update/delete methods, you just verify if the cookie that is being used to update/delete a particular record is the same one that you returned to the user when that record was locked. You're in the right path, you just have to add this verification to your update/delete methods and you're fine!


Please refer the statement in bold above.

Rajesh Moorthy wrote:I do not already have a value to compare it against the cookie.


If you are storing an association between the locked record and it's cookie on the server, then you do have a value to compare with the parameter passed in an update or delete method call.
 
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
Side note: Check your method signature for the lock method - in some instructions you may find that Map<Long, Long> may not be the best choice. Make sure you do not just use code that someone else has suggested without ensuring that it is actually suitable for your assignment or you could loose points.
 
Roberto Perillo
Bartender
Posts: 2271
3
Eclipse IDE Java Spring
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Andrew Monkhouse wrote:in some instructions you may find that Map<Long, Long> may not be the best choice.


Agreed. I had suggested Map<Long, Long> because, in the signature of the methods provided by Alexandre in the first post, the record is identified by a long value, as well as the cookie value, but I myself have a Map<Integer, Long> to control the locked records. The bottom line is, you have to create a structure that controls the locked records and enables you to identify which client locked a particular record.

Rajesh Moorthy wrote:Please refer the statement in bold above.


After locking a record, you have to guarantee that only the client that locked it can update or delete it. When locking a record, the client should own an id to be sent to the server for updating or deleting it. There, you have to verify if that id is the same one that was generated on the server side when that record was locked and given to that client. If so, then you can proceed and update or delete that particular record. And to unlock a record, you also have to check if the client that is unlocking it is the same one that previously locked it. If so, then you can, for instance, remove that particular record's entry from the Map and notify all clients that it has been unlocked.
 
Rajesh Moorthy
Ranch Hand
Posts: 30
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Thanks Andrew & Roberto for your suggestions.

My pseudocode for updateRecord looks the following now:



Do you feel this is the right way to proceed?

Thanks & Regards,
Rajesh.
 
Roberto Perillo
Bartender
Posts: 2271
3
Eclipse IDE Java Spring
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Howdy, Rajesh!

Do you feel this is the right way to proceed?


Yep!
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic