I am currently working on a project for a veterinary practice and one of its components is a web-based backoffice for general management. The practice already has a backoffice-style software, but it's lacking in some features and it's only required for legal reasons. I was thinking about the authentication process the other day and I came up with the following questions/scenarios:

  1. What will happen if I have two or more instances (tabs) of the backoffice opened in the same browser, on the same machine, with different user sessions? Will the session data for each user get corrupted? The reason for this is that there's only one computer in the practice for multiple workers.

  2. What if there are house calls and one vet has to stay behind in the practice, while the other goes away? Seeing that I'll be making the backoffice responsive, the vet that answers the house call could open an instance of it on a tablet and register the information on-site. But, at the same time, the other vet is, perhaps, also accessing the backoffice.

I don't know if I made myself clear, but I'm seeing a problem with session concurrency.

I'll be using MySQL as the database, I think it supports concurrent access to the tables.

Any ideas?

  • (1) seems like an odd requirement. By default, the same session is shared across multiple tabs in the browser opened to the same site. Having different users logged using different tabs to login to the same site seems like an inevitable security disaster. See stackoverflow.com/questions/368653/… for some interesting reading on this subject. (2) seems more realistic. It's common for sites to update when other users on the site take action - e.g. if you are on this page while another user answers or comments, you are alerted.
    – mti2935
    Commented Dec 9, 2021 at 1:48
  • Thanks for answering! I forgot about the "same session across multiple tabs" feature. It's just I was thinking about when sometimes we have two instances of a desktop program opened at the same time. Would the "session" be the same for both? For me, the behaviour of a web-based backoffice is trickier to understand when it comes to session management and the flow of data.
    – user271185
    Commented Dec 9, 2021 at 1:58
  • When your 'session' is tied to cookies or other persistent browser data, it will be relied upon by all tabs. However, I am unsure what you would expect to corrupt here. ' I'll be using MySQL as the database'; this shouldn't be an issue at all for backoffice apps.
    – Beltway
    Commented Dec 9, 2021 at 7:07
  • For DB updates, there are various ways to deal with concurrency issues... maybe read this: docs.microsoft.com/en-us/ef/ef6/saving/concurrency (asp.net) Also consider polling to alert about updates... (stackoverflow does this here when it tells you "a new answer has been posted", or "a change has been made to this post")... you have to decide which strategy works best for you. (In my intranet I check for changes between the current data and the "view" data in the form before updating... I fail the whole update if a change had been made in between display and submision.) Commented Dec 9, 2021 at 21:15
  • @Beltway Maybe when a pet's record is being accessed at the same time and, for some reason, two or more vets start to edit it and data gets corrupted. Those types of scenarios.
    – user271185
    Commented Dec 10, 2021 at 10:10

2 Answers 2


Managing different sessions in each browser tab is - as you imply - difficult. You can for instance manage login and state using tokens in session storage rather than using session cookies. In general, cookies will spoil your day. So while it's possible, it's probably not a good idea.

If users need to share a logged in computer (again, not a good practice), it's probably best if they create separate browser profiles instead. Then it will - as long as you don't rely on single sign-on from the OS, look like separate browsers from the perspective of your app.

Any standard database system (eg. PostgresSQL, MySQL) support concurrent access, so this is not an issue. The problems will be in your web front-end.

  • I see. It's a very small practice, not an hospital-like one. There's no user-role implemented, the program that is being used has only an "ADMIN" by default. I have a feeling that the owner won't be acquiring any more on-site laptops, but could invest in tablets, as they are more portable. Maybe they will also be shared by all employees or they could bring their own and access the backoffice. I don't know, this access behaviour has to be really well thought. Thanks for the tips!
    – user271185
    Commented Dec 10, 2021 at 10:03

What will happen if I have two or more instances (tabs) of the backoffice opened in the same browser, on the same machine, with different user sessions?

We don't know - you are writing the code, you define its behaviour.

While I've seen applications which try to address this by trying to ensure that sesions don't get split. It doesn't work. The solution is to ONLY store data relating to the user session in the session - i.e. authentication state (is user logged in?) username, autorization information (e.g. group membership) time of last interaction (for inactivity timeout). Never store application data in the session which might be updated - a cache of previous record ids might help navigation and is OK but stock adjustments are NOT OK. Be cautious about referencing the session from the application data.

Although you can't enforce split session protection, watching out for it will often minimise data corruption. Hint: the javascript window.name property is a good place to store specific indetifiers for the window accessing the data but do be aware this is a form of ever-cookie.

What if there are house calls and one vet has to stay behind in the practice...

I think you're asking how you ensure that concurrent access from different sessions on the same data does not cause conflicts. This requires some sort of locking mechanism. Applying locks is (relatively) easy, cleaning up locks is harder.

Firstly design your data model such that you minimise updates and deletes but instead favour inserts to reflect new data (this also provides for better auditability).

Next, since HTTP is stateless, and hence a logical transaction in terms of user interaction may span more than HTTP page, setup all your tables and updates with optimistic locking (e.g. last modified timestamp or serial number), include the lock values you retrieved as predicates on any update, design your code to handle the scenario where a lock conflicts results in the query failing to update the expected rows.

Another approach is to ensure exclusivity at the logical record level - i.e. have each "case" assigned to zero or one operators. This breaks when users start sharing logins.

You must log in to answer this question.