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

B&S: How to make Booking method atomic?

 
Darya Akbari
Ranch Hand
Posts: 1855
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi,

I have the B&S version 2.1.3 assignment which use the lockCookie variable.

Right now I try to figure out how the network layer design should look like.

In a previous post Andrew gave me the hint that the cookie must be handled by the client. So I like to provide a makeBooking(int recNo) method to my Remote Interface ContractorDatabaseRemote.

For the Remote Implementation ContractorDatabaseImpl I want guarantee that my booking method keeps the following (atomic) order:
  • lock - read - update - unlock

  • So far all my synchronized methods are in two Singleton classes LockMaster and Database, see my other thread B&S: Data Layer Design with Singleton?

    How can I guarantee that my makeBooking is not interrupted by other Threads and keep it's atomic order

    Regards,
    Darya
    [ March 29, 2005: Message edited by: Darya Akbari ]
     
    Yevgeniy Treyvus
    Ranch Hand
    Posts: 48
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    A better way to implement this would be to NOT make your client(s) interact with the cookie mechanism at all. In other words, the entire locking sequence can be done on the server side in a method that will be synchronized based on the record at hand -- this will ensure an atomic operation.

    I think this is a better approach for various reasons. Primarily, you have more control. If the client dies, you don't care, as the lock-update-unlock sequence is done on the server. Another benefit is that if you force the client to first get the cookie, then call update and then call the unlock, that's three networked calls. It is preferable, I think, to have only one (e.g. update) and the server should be required to handle the calls to Data.lock, Date.update and finally Date.unlock.

    [ March 29, 2005: Message edited by: Yevgeniy Treyvus ]
    [ March 29, 2005: Message edited by: Yevgeniy Treyvus ]
     
    Darya Akbari
    Ranch Hand
    Posts: 1855
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    Hi Yevgeniy,

    thanks for your response.

    Like you I first favored the server side solution simply because I don't want annoy the Client with the cookie handling. Your reasons added to this even strenghten me for the server solution.

    But it irritates me, that Andrew means the Client must handle the cookie, see the thread B&S: Handling different data files (format, schema)? at the bottom.

    Andrew, can you give some reasons why the client should handle cookies?

    Regards,
    Darya
     
    Yevgeniy Treyvus
    Ranch Hand
    Posts: 48
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    There are really a couple of ways of handling it. I used socket, so maybe in an RMI solution it's a little bit different, but I don't think the client *must* handle the cookie. It's really up to your implementation.

    Initially I started with the client locking approach, but realized that it was bulky and slow. I think the server-side solution is cleaner.

    Moreover, doing so abstracts the client from having to worry about locking -- the client really doesn't need to know anything about how locking is implemented. In fact, it does not have to know that any locking activity is taking place.

    I think this approach is more flexible because if in the future you (your the boss) decide to switch to another way of handling locking, the client won't have to change. I did it this way and got 80/80 on locking. But really there are several ways of doing and I am sure you can get the full points if you initiate the locking on the client side.
     
    Darya Akbari
    Ranch Hand
    Posts: 1855
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    Of course your 80/80 in locking speak for itself. Your arguments are also clear. I hope Andrew can give some of his reasons so I get the whole picture. In the meantime I will make a server side solution.

    Yevgeniy, congratulations for your passed exam.

    Regards,
    Darya
     
    Darya Akbari
    Ranch Hand
    Posts: 1855
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    Andrew did that discussion already . Here is the horrible long thread I found Should lock methods be callable by the client.

    Seems I need to read this thread too to make up my minds whether client-side or server-side solution.

    Regards,
    Darya
     
    Yevgeniy Treyvus
    Ranch Hand
    Posts: 48
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    Indeed this topic has been well discussed Maybe I should have read these posts before I started my project...that probably would have saved a lot of time. Regardless, I think I you can do it either way as long as you document your design decisions in the choices.txt file.

    Good luck!
     
    Darya Akbari
    Ranch Hand
    Posts: 1855
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    Thanks Yevgeniy, I am still reading the thread .

    Regards,
    Darya
     
    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
    Hi Darya,

    In a previous post Andrew gave me the hint that the cookie must be handled by the client.


    I deliberately tried to fence sit on that one, and obviously failed miserably. What I said in that other post was "The client of Data must get the cookie when it calls the lock method, then use it in the calls to update and unlock."

    What I was trying to imply here was that the class that is (ultimately) calling the methods of Data class must handle to cookies. In this respect, the class that is (ultimately) calling the methods of Data class is the client of Data. This is slightly different from the "Client" who has asked us to write this software, or their "client" for whom the bookings are made, and might be different from the client application.

    Andrew did that discussion already . Here is the horrible long thread I found Should lock methods be callable by the client


    Yes, all my reasoning for why my interpretation of the instructions require the lock cookie to be processed by the client application is in that thread. (And, for that matter, why all the methods of Data class should be callable by the client application).

    I understand Yevgeniy's comments, and in the real world (where we can sit down and talk to the customer) I would also want to move some (or all) of the business logic to the server for many of the reasons he suggests. But I am not convinced that the instructions allow for this.

    But at the end of the day (and, as mentioned several times in "Should lock methods be callable by the client") the end decision does seem to be up to you - you have to make a design decision (and document it).

    Regards, Andrew
     
    Darya Akbari
    Ranch Hand
    Posts: 1855
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    Hi Andrew and all others ,

    I know you meant the client of the Facade class Data. In this case I think that the Remote Implementation in my network layer is the client for my Data class.

    Hence I plan to create a synchronized makeBooking(recNo) method to make sure that my booking procedure is an atomic operation. However I was confused having the synchronized keyword in my network layer (RMI) because all other synchronized methods are in my Adaptee class Database (reading the data file).

    Since RMI plays a role (RMI and its internal handling of Threads) I am not sure whether my synchronized makeBooking(recNo) is in the right place.

    Can someone clarify this

    Regards,
    Darya
    [ March 30, 2005: Message edited by: Darya Akbari ]
     
    Uriy Kashtanoff
    Greenhorn
    Posts: 7
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    Yevgeniy, congratulations on 80/80 for locking. I agree that from the development perspective exposing only book (long recNo, String owner) method to the client is simpler and more straight-forward. In fact, I'd like to do just that in my implementation. However, if the locking is encapsulated inside of some sort of Data Access Object (the one that would have the above "book" method), then I am not sure if what happens in the following situation is acceptable.

    Suppose two customer service representatives (say, Petya and Vasya) search for available resources roughly at the same time. The GUI will present them with some sort of a listing from which they can pick out the desired resource to book. What if they decide to book the same resource? If Petya gets to the "book" method first, then inside of it the lock-update-unlock happens. But then Vasya's request will come through next and do the same thing. So at the end, the last person wins. The question is, what good is locking then?

    Of course, I am sure that in your implementation you did something like lock-read-(make sure that it can be booked, throw exception if not)-update-unlock. With this in mind, in the above example, the second person would then get an error message saying something like "Sorry, but someone already beat you to this resource". This might be OK, but what about all that "cookie" business in conjunction with the locks?

    This brings me to what seems like a more user-friendly solution, which would unfortunately require locking capability from the client. After getting the listing of available resources, selecting one of them would not try to book it, but instead would "check availability". First, that record would be locked, and then re-read (just in case it was updated after initial searching). If the locked record still exists and has not been booked, then the user would be presented with an option to book it. The booking operation would update and unlock the record.

    You know what, I think I just convinced myself of how I should do this while describing my concernes to you guys. I would still like to hear what you think. Thank you for reading this.
     
    • Post Reply
    • Bookmark Topic Watch Topic
    • New Topic