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

Booking contractor and using lock cookie strategy questions

 
David Pantale
Ranch Hand
Posts: 32
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi there folks!

I'd appreciate it if someone could comment on my strategy, such as it is. I've noticed on a couple of threads arguments that the lock cookie should be sent back to the client. But I think that's just in the case where there is a thick client. In my case (B&G) I'll have a thin client that, when updating/booking, gets the contractor value from the user and invokes the business services class method bookContractor that's on the server (and passes the contractor number). The business services class will have my singleton implementation of the required methods (all synchronized) as well as a updateContractor method (not synchronized) that does the actual lock / update / unlock method calls. I keep the business services interface very simple (2 methods - bookContractor(String) and getContractors(String[]). The singleton's updateContractor method is not synchronized since I want to allow other threads the opportunity to do work. Does this basic strategy seem sound? Also, since all the booking work is done on the server there is no point in sending the lock cookie back to the client. I'll simply save it in a local variable in the updateContractor method (which makes it thread safe) and use it when necessary. Am I in trouble here?

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

I've noticed on a couple of threads arguments that the lock cookie should be sent back to the client. But I think that's just in the case where there is a thick client.


That is correct. In the thin client scenario, you can just have a remote service, like bookRoom(String client, int recordNumber), and call it from the client side. On the server side, you'll call the lock() method, get the cookie returned from it, call the update method using this cookie and unlock the record using the cookie again. All this is done on the server side, so you don't have to return the cookie to the client. The cookie will only be handled on the server side. The difference is that, if you wanted to go for a thick client, it would be a lot easier, since you have the cookie number.

Does this basic strategy seem sound?


Well champ, I think you are in the right path. Just make sure everything is working well concurrently and be happy!
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic