• Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

when Locking event is trigger

 
Ruben Guillen
Greenhorn
Posts: 28
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Dear All

I would like to get guidance on when the locking event is triggered.

I have designed a UI where the user will have a table with the rooms available and beside each row there will be a update command button. when the user press the update button then the system will try to lock the record, then a separate windows will be displayed with the form-like displays of the selected record and allow the user to enter information of the customer, then there will be a confirmation of the change, but this is just to confirm the change and liberate the lock. What could happen is that the user opens the form-like window and stays there for hours without confirming or cancel and keep the lock of the record.
I was wondering if this implementation was used by others people also, or if you just tried to lock the record when the user has entered the customer information and try to confirm the saving, then user press save button and only then you try to lock and if the lock is available then lock, save and then unlock.

Another option I was taking in account is to allow the user to select several rooms for one update for one customer. Something like a check-box that will allow the user to select several rooms and then a separate update button that will display a separate window and also will lock selected rooms and in this separate window the user will enter only one time the code of the customer and update all selected records.

Any comment is welcome.

Regards
 
Roel De Nijs
Sheriff
Posts: 10666
144
AngularJS Chrome Eclipse IDE Hibernate Java jQuery MySQL Database Spring Tomcat Server
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Ruben Guillen wrote:if you just tried to lock the record when the user has entered the customer information and try to confirm the saving, then user press save button and only then you try to lock and if the lock is available then lock, save and then unlock.

That's the approach I followed. Because my opinion is: keep the interval a record is locked as short as possible.

And regarding your checkbox-approach: it's not required, so why would you spend your time on something unnecessary.

Kind regards,
Roel
 
Nicolas Kal
Ranch Hand
Posts: 69
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Ruben,

I believe that you can use either of the locking mechanisms as long as you justify your options and explain any issues that may occur from you choise. For instance, Locking during save will not face the scenario of locking a record for hours as you said, but it may result in incosistent data. On the other hand as you have said correctly the other way might lock a record and block it if the user doesnot unlocks it. I participated in the development of commercial software and for the case of locked records an administrator unlocks it after it has been reported as "blocked". You may assume it and mention it as a possible enhancement in later version to overcome this. Of course and you are not obligated to implement it since it is not required from the specifications.

Hope I helped,
Nicolas
 
Nicolas Kal
Ranch Hand
Posts: 69
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Roel De Nijs wrote:And regarding your checkbox-approach: it's not required, so why would you spend your time on something unnecessary.


I definetely agree with Roel, after all the instructions specify that no extra credit will be given for implemented what is not required

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

I have designed a UI where the user will have a table with the rooms available and beside each row there will be a update command button. when the user press the update button then the system will try to lock the record, then a separate windows will be displayed with the form-like displays of the selected record and allow the user to enter information of the customer, then there will be a confirmation of the change, but this is just to confirm the change and liberate the lock. What could happen is that the user opens the form-like window and stays there for hours without confirming or cancel and keep the lock of the record.


Although I think this may be a valid approach, I'd say it isn't the most appropriate one. In order to avoid a record to be locked forever, you would have to implement some kind of timeout code, so this locking could be released anyway... but this would be over complicating things. I'd say that the most appropriate approach would be to lock a record just before updating it, so you would have lock()/update()/unlock() in a row.

And about the check boxes, they aren't really necessary. All you have to do is allow the user to update one record at a time.
 
Ruben Guillen
Greenhorn
Posts: 28
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Dear All

Thank you very much for all your comments. Now it is clear for me, I will follow your recommendations.

Regards.
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic