Is there a practical limit to the number of process's/threads that can somewhat simultaneously access an RDBMS ? I am assuming that to access an RDBMS a process/thread first establishes a connection to a local or a remote RDBMS and acquires a connection
handle to the RDBMS, access's the RDBMS and performs all its transactions using that connection handle, assuming a single RDBMS can have many schemes and many tables within a scheme, and then finally closes its connection. So is the background database
process or daemon which can act as a server preferable, where the client library always communicates with the relevant server or is a simple shared library using shared memory preferable. If the number of such connections that can be established can be
large then the client-server model might necessarily have to be used.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 2020-04-02, sundaresh.venugopal@gmail.com <sundaresh.venugopal@gmail.com> wrote:

Is there a practical limit to the number of process's/threads that
can somewhat simultaneously access an RDBMS ?

It mostly depends how much you want to spend.

--
Jasen.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Friday, April 3, 2020 at 10:32:41 AM UTC+5:30, Jasen Betts wrote:

Is there a practical limit to the number of process's/threads that
can somewhat simultaneously access an RDBMS ?

It mostly depends how much you want to spend.

--
Jasen.

Time and Effort already quite a lot and am willing to do more, but have an up and coming fairly OK system which I am pretty proud of. Will work equally well as a DRDBMS with fragmentation and so forth, but in terms of money, zilch.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)