• Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

Lock / unlock in the GUI?

 
Michael Couck
Ranch Hand
Posts: 46
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi,
Background:I've implemented a cache in memory, the key is the recNo, and also the position in the file.
The spec states record locking but no mention as to why. If your write / update functions are synchronized then why go to all the trouble o locking first, my reasoning for this is for the user / GUI to specifically lock a record before updating and reserving it i.e. buttons on the GUI for locking and unlocking.
From the business perspective this makes sence while on the phone for example to lock the record that no other CSR can then book the same record. Without which even though the record will be locked before the write or update, two consecutive reservations could lead to the first being undone by the second. I see here that no one has done this and I am a little nervous that I have misinterpreted this.
My second question is on the threading thingy again.
Multiple clients? So several clients access the server at the same time, does this mean some kind of thread pool, each client getting a new thread for their action. Overkill? My impression is that the only threading issues is the synchronization on write / update. Once again I am a little unsure because the spec specifically states that if locking is to be done and the record is locked the current thread should sleep until the lock is undone. Hmmm . . . I am confusing myself . Anywayz it is pretty late here, when I wake up perhaps there will be some enlightenment from someone, and start with a clear head again.

See ya
Michael
 
Philippe Maquet
Bartender
Posts: 1872
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Michael,

Welcome to this forum.
I am a little nervous that I have misinterpreted this.

I may understand that.
Locking is in your specs, meaning that you cannot avoid it. Now, it shouldn't be under the user control. I don't know if you got a version with lock cookies or not, but if it's the case it's even impossible for you to update a record without getting a lock before. And if it's not the case, you must lock records before updating (or deleting) anyway according to your specs.
The typical use case for booking is this :
  • Users perform a search and get a list of bookable records displayed in a JTable.
  • To book such a record, they select it, enter some customer ID and click a "Book" button.
  • Server-side, you have a book() business method.
  • That book() method locks the record, re-read it, and checks if the record is still bookable (because another user could have booked it).
  • If it's OK, it updates the record.
  • If not, it throws some application exception (with a message like "Record booked already")


  • Best,
    Phil.
     
    Michael Couck
    Ranch Hand
    Posts: 46
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    Hi Phil,

    Thank you for the help. I think I'll use the method you suggested. Will mean some changes because I have already implemented the lock as a user function, what a pain. But it will certainly simplify matters.
    One small question if I may. Once the record is then booked, in your scenario above, it then gets unlocked? And then another user can change details or allocate another guest to the room, i.e. change the owner? So the lock is only held on the record from the time the update starts until the record is updated, then the lock is released? Or does the lock persist.
    From your solution I infer that the lock is relenquished. Which is far simpler than my model as it stands now. However say for example two users send a mesage to book a room within 0.1 seconds of each other, the two instructions stand in line to update / book the room, the first changes the owner, then the second changes the owner, the first user will be a little supprised to see that his / her booking data is incorrect, unknowing of course that two updates have taken place seemingly concurrently. Is this a little tricky business from the boys at Sun?
    Having a look at the GUI I have done will clarify what I have done, perhaps you can tell me if it looks anything like yours. GUI
    Thanks again.
    I read that a Philippe is uploading his agisnment, is that you? Well good luck!
    All good things come to those who wait.
    See ya
    Michael
     
    Philippe Maquet
    Bartender
    Posts: 1872
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    Hi Michael,
    One small question if I may. Once the record is then booked, in your scenario above, it then gets unlocked?

    Yes, of course. Sorry I missed it above.
    And then another user can change details or allocate another guest to the room, i.e. change the owner?

    Once a room is booked by someone, it cannot be booked by anyone else anymore.
    So the lock is only held on the record from the time the update starts until the record is updated, then the lock is released? Or does the lock persist.

    A lock is temporary by nature.
    Having a look at the GUI I have done will clarify what I have done, perhaps you can tell me if it looks anything like yours. GUI

    Besides the Lock / Unlock buttons which are useless, I think that :
  • You don't need other search criteria in your GUI than Name/Location
  • As the GUI performs an exact-match search comboboxes populated with unique criteria values (+ a "Refresh" button to update them) would be handy. If you choose that solution, think of putting a "[ANY]" item in them to represent the server-side null criteria.
  • Delete must not be implemented in the GUI (as create BTW)
  • I guess that you book a room in a different mode (Mode menu ?), as I don't see any Book button neither any JTextField to enter the owner. When you'll get rid off of your first search panel (all criteria), you'll probably have room under the remaining search panel to put there a Book panel, in such a way that the whole stuff is managed on the same screen.


  • I read that a Philippe is uploading his agisnment, is that you? Well good luck!

    Unfortunately not !
    Best,
    Phil.
     
    Michael Couck
    Ranch Hand
    Posts: 46
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    Thanks Phil! You have been a great help, I know exactly what I need to do.

    See ya
    Michael
     
    • Post Reply
    • Bookmark Topic Watch Topic
    • New Topic