Multi-tenant scaling

[Laurens_van_Run]

We are looking for ways to scale RemoteDb in our setup. We can have hundreds of clients connection and want it to scale nicely.

Therefore we prefer to be able to:

1. connect to the database defined in the JWT (which we use for authentication), instead of seperate URIs for each database (as adviced in other topics).
2. be totally stateless. As far as I can see, this is not possible with the current code, because it holds a list of databases and transaction details in memory.

Can you please advice us in both situations?

[wlandgraf (Wagner Landgraf)]

Dear @Laurens_van_Run

1. connect to the database defined in the JWT (which we use for authentication), instead of seperate URIs for each database (as adviced in other topics).

It's possible, but requires a little more effort. You should then create your own RemoteDB module inheriting from TRemoteDBModule, and override the CreateConnection method.

In such method, you can create a database connection interface (IDBConnection) with any setting you want, and you can inspect the request, including Authorization/JWT, to decide how to create your database.

It was explained in a previous support topic here:

Remote DB and JWT data

I have set up an application server with sparkle that supports several http requests and remoteDB. For authentification I use JWT. I would like to use data from the JWT when logging into the database for setting session-variables in the DB Firebird) for using in triggers (user, machine, ip-address) for the audit trail. I read a lot about switching off remoteDB authentication by setting password and user to "" but I just do not manage to access the jwt credentials when creation the database co…

1. be totally stateless. As far as I can see, this is not possible with the current code, because it holds a list of databases and transaction details in memory.

Correct. The issue is not the impossibility of "current code", but of the architecture itself.

If you request to open a transaction from the client, such transaction has to remain open in the server. If you load-balance the server, there is no guarantee the next request will come to the correct server.

Unless you create really complex rules in your load-balancer/reverse proxy that guarantees the request forwarding to the correct server, based on the remdb-db-id HTTP header (that's what RemoteDB uses to identify the DB).

Thus, if you are able to configure a load-balancer that always forward the requests to the same server if the remdb-db-id is the same, then is should work.