From email@example.com@21:1/5 to All on Thu Apr 2 04:06:20 2020
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.
From firstname.lastname@example.org@21:1/5 to Jasen Betts on Fri Apr 3 00:28:00 2020
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.
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.