locked
asp.net mvc5 prevent users viewing the same page simultaneously RRS feed

  • Question

  • User1408348798 posted

    Hello. Please help me with the following problem: I developed in mvc 5 an application in which I would like a view page can be accessed only once at that time, the second person who wants to enter at the same time to be redirected to another page where to get a message "please come back later for the moment is busy". After the user leaves the page, it can be accessed by another user. I also specify that everyone has a username and password and use the default mvc5 template to login. Please help me with a solution.

    Thursday, December 10, 2020 7:08 PM

Answers

  • User475983607 posted

    The main function of a website is to allow many users to access shared resources from a single application.  You are purposely breaking this core feature.

    One way to achieve your requirement is using standard MVC state management which is well known and documented.  The ingredients are a Cookie or Session, a database and table, and a query.  

    On every request check the database to see if a the page is available.  If the page is available, Create a new GUID.  Add the GUID to a Cookie or Session.  Insert a table record that has, at least, the GUID, future timeout DateTime, and the Page to checkout.   The query logic is very simple, filter the table by page and where the current DateTime is less than the timeout column.  If a record does not exist then the page can be checked out.  If the record exists then compare the GUID in Session (or Cookie) with the GUID in the record.  If the GUIDs match then update the timeout.  Otherwise, deny access and redirect.

    The flow above assumes a sliding expiration.  It's your responsibility to understand the business process and design the application flow.  

    • Marked as answer by Anonymous Thursday, October 7, 2021 12:00 AM
    Friday, December 11, 2020 2:09 PM

All replies

  • User1120430333 posted

    It sounds like a very poor design.

    Thursday, December 10, 2020 8:36 PM
  • User1408348798 posted

    Hi. Please help me with a simple idea of where to start.

    Thank you!

    Friday, December 11, 2020 8:01 AM
  • User1120430333 posted

    My advice to you is to abandon this, because it's  not viable IMHO.

    Friday, December 11, 2020 1:40 PM
  • User475983607 posted

    The main function of a website is to allow many users to access shared resources from a single application.  You are purposely breaking this core feature.

    One way to achieve your requirement is using standard MVC state management which is well known and documented.  The ingredients are a Cookie or Session, a database and table, and a query.  

    On every request check the database to see if a the page is available.  If the page is available, Create a new GUID.  Add the GUID to a Cookie or Session.  Insert a table record that has, at least, the GUID, future timeout DateTime, and the Page to checkout.   The query logic is very simple, filter the table by page and where the current DateTime is less than the timeout column.  If a record does not exist then the page can be checked out.  If the record exists then compare the GUID in Session (or Cookie) with the GUID in the record.  If the GUIDs match then update the timeout.  Otherwise, deny access and redirect.

    The flow above assumes a sliding expiration.  It's your responsibility to understand the business process and design the application flow.  

    • Marked as answer by Anonymous Thursday, October 7, 2021 12:00 AM
    Friday, December 11, 2020 2:09 PM
  • User753101303 posted

    Hi,

    Or tell us first which problem you are trying to solve?  If worried about concurrent db updates ,a common approach is to use "optimistic concurrency".

    Locking beforehand would be rather if you really expect they multiple users will try very frequenlty to update the same data (which for most apps would likely point rather to some kind of organizational issue ???)

    Friday, December 11, 2020 2:46 PM
  • User1408348798 posted

    Dear Mgebhard, you gave me an idea of where to start. Thank you and happy holidays.

    Friday, December 11, 2020 2:50 PM
  • User1408348798 posted

    Dear PatriceSc. The flow is as follows: an user enters the view edit page and enter the data into the database, until he finishes entering another person not to be able to access the view edit page until he is left by the first user.  And I would like to know how I can find out that the view edit page is busy at that moment.

    Thanks for your time.

    Friday, December 11, 2020 2:59 PM
  • User753101303 posted

    And you'll lock users even if they are not working on the same data?

    With "optimistic concurrrency" users can still work on the same edit page. Each db row comes with a "version" column that is updated automatically. Updates are done using both the pk and this "version" information in the where clause and as a result:
    - if someone tries to change the same row since it was read , the row won't be found any more (as the version doesn't match) and you can now handle conflicts when they really happen. Also in my experience, users are rarely working on the same data.

    "Pessimistic locking" especialy at the page level could make your app barely usable. Or are you really in a case where you expect the same data to be very frequently upated by the same user ??? 

    Friday, December 11, 2020 3:29 PM
  • User-474980206 posted

    generally you use table in a database. typically the lock would have a timeout, say the user opens the page and walks away or closes the browser. so the flow is:

    user fetches page =>

         if no lock create a new lock for the user
         if already a lock and its the same user renew the lock
         if expired lock, delete the lock and and create new lock
         else redirect to locked page (note, be sure test and set is an atomic operation). 

    user saves page =>

        if user still has lock save data and redirect to success else redirect to lost lock

    Friday, December 11, 2020 4:12 PM
  • User1120430333 posted

    It seems to me that you are talking about stopping two or more users from editing/updating the same record concurrently. You're talking about a record lock condition and not some kind of Web page user lock condition. You should be looking into record lock conditions that have been discussed in the thread.

     

    Friday, December 11, 2020 10:49 PM