Multiple connections for one user

Question

I am trying to determine the best / "right" place to put the following logic on my Delphi data server.

The user connects to the server and uses the provided credentials. I check them using a centralized authorization database (Oracle database). If they are really valid users, I want them to give them a connection with where their data is actually located, based on what the authorization repository says (it could be a different host, database, username, password).

I have an AuthorizationDatabase in my own server class, which is the server life cycle, since no one can log in without verification there. Does this create a problem with concurrency? 10 users who will be checked at the same time, will this work fine?

I have a basic server module from which all session-level data modules that are connected to the application are derived. Application connection settings may vary depending on the user's login to the system.

The problem I encountered is the place where you need to perform the process of assigning authorization / verification / new DB parameters.

Where is this approach to a two-step database suitable? It seems quite common that the user is checked in one place, but the data that they will ultimately access is in another.

When considering the examples, I do not see the obvious place to which he will go.

Answer 1

You cannot split one connection into several sessions; you will receive a “Read Error” message or another error when 2 sessions try to read the database at the same time.

But you may have a centralized place to log in, just make it thread safe, it will do:

TMonitor.Enter(LoginDM); Try valid := LoginDM.Login(username, password); finally TMonitor.Exit(LoginDM); end; 

User information, since each user will have his own session that is running in the thread, you can create one connection for the ServerClass instance and define the life cycle for the "session", so each new session will spawn a new ServerMethod instance class and have its own connection. this way you don’t have to worry about how you write your server methods, since they will always have their own exclusive connection.