Database Connection vs Raw TCP Connection












2














I have some fundamental questions about how database clients & database interact




  1. Do databases support multiple transactions simultaneously on a single database connection from client? If not, why not? (as multiplexing would save on resource overhead per connection & connection pools are a source of contention when thousands of simultaneous queries needs to be executed simultaneously, which multiplexing for sure avoids)

  2. Whats the relationship between database client's level Connection vs physical raw TCP connection. Is it many-to-one[multuplexing] (or) one-to-one? If not multiplexed why not?

  3. If multiplexed, does the database server maintain a single logical connection from its end (or) multiple logical connections


PS: I understand some of these details will vary from database to database, buit want to know in general how popular implementations such as Postgres, Mysql, Oracle, SQL server & DB2 implement these










share|improve this question









New contributor




Ashok Koyi is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
















  • 2




    Note that TCP connections aren't physical... maybe they're close enough from a database system perspective, but an actual physical connection is a wire.
    – immibis
    2 hours ago










  • Sure, I should have used the word RAW TCP connection
    – Ashok Koyi
    42 mins ago










  • BTW I feel that TCP protocols of databases are notoriously bad. Most don’t support multiplexing and they typically use blocking reads for the time of operations. This is bad since it ties read timeouts to operation timeouts and it makes reconnects harder.
    – eckes
    28 mins ago
















2














I have some fundamental questions about how database clients & database interact




  1. Do databases support multiple transactions simultaneously on a single database connection from client? If not, why not? (as multiplexing would save on resource overhead per connection & connection pools are a source of contention when thousands of simultaneous queries needs to be executed simultaneously, which multiplexing for sure avoids)

  2. Whats the relationship between database client's level Connection vs physical raw TCP connection. Is it many-to-one[multuplexing] (or) one-to-one? If not multiplexed why not?

  3. If multiplexed, does the database server maintain a single logical connection from its end (or) multiple logical connections


PS: I understand some of these details will vary from database to database, buit want to know in general how popular implementations such as Postgres, Mysql, Oracle, SQL server & DB2 implement these










share|improve this question









New contributor




Ashok Koyi is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
















  • 2




    Note that TCP connections aren't physical... maybe they're close enough from a database system perspective, but an actual physical connection is a wire.
    – immibis
    2 hours ago










  • Sure, I should have used the word RAW TCP connection
    – Ashok Koyi
    42 mins ago










  • BTW I feel that TCP protocols of databases are notoriously bad. Most don’t support multiplexing and they typically use blocking reads for the time of operations. This is bad since it ties read timeouts to operation timeouts and it makes reconnects harder.
    – eckes
    28 mins ago














2












2








2







I have some fundamental questions about how database clients & database interact




  1. Do databases support multiple transactions simultaneously on a single database connection from client? If not, why not? (as multiplexing would save on resource overhead per connection & connection pools are a source of contention when thousands of simultaneous queries needs to be executed simultaneously, which multiplexing for sure avoids)

  2. Whats the relationship between database client's level Connection vs physical raw TCP connection. Is it many-to-one[multuplexing] (or) one-to-one? If not multiplexed why not?

  3. If multiplexed, does the database server maintain a single logical connection from its end (or) multiple logical connections


PS: I understand some of these details will vary from database to database, buit want to know in general how popular implementations such as Postgres, Mysql, Oracle, SQL server & DB2 implement these










share|improve this question









New contributor




Ashok Koyi is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.











I have some fundamental questions about how database clients & database interact




  1. Do databases support multiple transactions simultaneously on a single database connection from client? If not, why not? (as multiplexing would save on resource overhead per connection & connection pools are a source of contention when thousands of simultaneous queries needs to be executed simultaneously, which multiplexing for sure avoids)

  2. Whats the relationship between database client's level Connection vs physical raw TCP connection. Is it many-to-one[multuplexing] (or) one-to-one? If not multiplexed why not?

  3. If multiplexed, does the database server maintain a single logical connection from its end (or) multiple logical connections


PS: I understand some of these details will vary from database to database, buit want to know in general how popular implementations such as Postgres, Mysql, Oracle, SQL server & DB2 implement these







sql-server mysql postgresql oracle connections






share|improve this question









New contributor




Ashok Koyi is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.











share|improve this question









New contributor




Ashok Koyi is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.









share|improve this question




share|improve this question








edited 42 mins ago





















New contributor




Ashok Koyi is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.









asked 15 hours ago









Ashok Koyi

1165




1165




New contributor




Ashok Koyi is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.





New contributor





Ashok Koyi is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.






Ashok Koyi is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.








  • 2




    Note that TCP connections aren't physical... maybe they're close enough from a database system perspective, but an actual physical connection is a wire.
    – immibis
    2 hours ago










  • Sure, I should have used the word RAW TCP connection
    – Ashok Koyi
    42 mins ago










  • BTW I feel that TCP protocols of databases are notoriously bad. Most don’t support multiplexing and they typically use blocking reads for the time of operations. This is bad since it ties read timeouts to operation timeouts and it makes reconnects harder.
    – eckes
    28 mins ago














  • 2




    Note that TCP connections aren't physical... maybe they're close enough from a database system perspective, but an actual physical connection is a wire.
    – immibis
    2 hours ago










  • Sure, I should have used the word RAW TCP connection
    – Ashok Koyi
    42 mins ago










  • BTW I feel that TCP protocols of databases are notoriously bad. Most don’t support multiplexing and they typically use blocking reads for the time of operations. This is bad since it ties read timeouts to operation timeouts and it makes reconnects harder.
    – eckes
    28 mins ago








2




2




Note that TCP connections aren't physical... maybe they're close enough from a database system perspective, but an actual physical connection is a wire.
– immibis
2 hours ago




Note that TCP connections aren't physical... maybe they're close enough from a database system perspective, but an actual physical connection is a wire.
– immibis
2 hours ago












Sure, I should have used the word RAW TCP connection
– Ashok Koyi
42 mins ago




Sure, I should have used the word RAW TCP connection
– Ashok Koyi
42 mins ago












BTW I feel that TCP protocols of databases are notoriously bad. Most don’t support multiplexing and they typically use blocking reads for the time of operations. This is bad since it ties read timeouts to operation timeouts and it makes reconnects harder.
– eckes
28 mins ago




BTW I feel that TCP protocols of databases are notoriously bad. Most don’t support multiplexing and they typically use blocking reads for the time of operations. This is bad since it ties read timeouts to operation timeouts and it makes reconnects harder.
– eckes
28 mins ago










3 Answers
3






active

oldest

votes


















9















Do databases support multiple transactions simultaneously on a single database connection from client?




For SQL Server, no.




If not, why not? (as multiplexing would save on resource overhead per connection)




It would seriously complicate the network protocol, which has to be implemented on multiple client platforms, creating a possible source of bugs and performance issues.



And the resource overhead caused by multiple connections is small, and largely mitigated by connection pooling, where a set of long-lived connections is shared among all the threads in a client program.






share|improve this answer























  • Assuming that you have thousands of simultaneous requests, wouldn't multiple requests compete for connections even in the pool? If simultaneous transactions are supported (I understand the complexity, but then non blocking IO is complex but servers do support it for performance reasons), we dont even need to worry about connection contention in pool & the performance should be much better than connection pools
    – Ashok Koyi
    13 hours ago








  • 4




    A TCP/IP connection is simply not an expensive enough resource to merit this design. The performance would probably not be "much better", and it might be worse as sessions would have to coordinate the utilization of the TCP/IP socket with other sessions wanting to read and write data.
    – David Browne - Microsoft
    12 hours ago










  • I've heard that postgres has a process/connection => a fixed overhead (~10MB) per connection, even if TCP connection overhead is small. Multiplexing looks to me like an attractive proposition there. Are there any downsides of multiplexing in that case?
    – Ashok Koyi
    12 hours ago












  • Right, but the costly thing is a session, not a network TCP/IP connection. Connection Pooling, and Application Server thread pools both enable "multiplexing", where 1000s of application users can share 10s of database sessions.
    – David Browne - Microsoft
    12 hours ago












  • But not simultaneously, is that correct?
    – Ashok Koyi
    12 hours ago



















2














The parallelism you hint at in Q1 is oversold. Even when you can do things in parallel, the system bogs down for many reasons:




  • Hit a brick wall of some resource: CPU / Network / Disk I/O / etc.

  • There will be "critical sections" and other interlocks to prevent stepping on each other. For "a few" connections / transactions / etc, this is not a big deal. But even at a few dozen, the system begins to noticeably stumble over itself.

  • Some multi-threaded applications hit an algorithm brick wall. Sorting is a classic example. Maybe you can launch a hundred threads (and get nearly a hundred-fold speedup) to compute the items in a big list, but if you need the resultset to be sorted, the application will not be able to get anywhere near the hundred-fold speedup in that phase. And then you have to funnel all the data into a single stream for delivering!


Databases are easier to design if you stop with the necessary requirement: separate clients must not step on each other. Then, within a single client, it is easier to focus on doing one thing at a time.



Learn about KISS.



As for the TCP layer -- You have the opportunity to design a router that can achieve what you suggest. You could make millions. But it belongs at a low level, not in the database engine.






share|improve this answer





















  • You are making multiple assumptions about the usecases here. Everything you said is equally applicable whether the connection is multiplexed (or) not. I'm talking from the point of view of fundamentals of what an ideal database client should look like. The resource utilisation is there whether you have multiplexed/non multiplexed transactions. But the non-multiplexed are always costly as each connection has a fixed overhead (incase of postgres a process/connection=~10MB space). Non blocking IO does not follow KISS (as its quite complex), yet all performance critical applications use it
    – Ashok Koyi
    12 hours ago



















2














Oracle



It is a little-known fact, that in Oracle, one can have 0, 1 or even more sessions in the very same TCP connection.



This is discussed in the book Expert Oracle Database Architecture (ISBN 978-1-4302-6299-2, Authors: Kyte, Thomas, Kuhn, Darl) in Chapter 5 - Oracle Processes.



https://books.google.com/books?id=NG4RpD8aLEIC&pg=PA170




Connections vs. Sessions



It surprises many people to discover that a
connection is not synonymous with a session. In most people’s eyes
they are the same, but the reality is they do not have to be. A
connection may have zero, one, or more sessions established on it.
Each session is separate and independent, even though they all share
the same physical connection to the database. A commit in one session
does not affect any other session on that connection. In fact, each
session using that connection could use different user identities!
In
Oracle, a connection is simply a physical circuit between your client
process and the database instance — a network connection, most
commonly. The connection may be to a dedicated server process or to a
dispatcher. As previously stated, a connection may have zero or more
sessions, meaning that a connection may exist with no corresponding
sessions.




Demo:



Log in to the database:



[oracle@o71 ~]$ sqlplus bp/bp@'localhost:1521/min18'

SQL*Plus: Release 18.0.0.0.0 - Production on Thu Dec 27 21:20:03 2018
Version 18.4.0.0.0

Copyright (c) 1982, 2018, Oracle. All rights reserved.

Last Successful login time: Thu Dec 27 2018 21:07:47 +01:00

Connected to:
Oracle Database 18c Enterprise Edition Release 18.0.0.0.0 - Production
Version 18.4.0.0.0

SQL>


In another session, started somewhere else, query the sessions of BP:



SQL> select sid, process, port, paddr from v$session where username = 'BP';

SID PROCESS PORT PADDR
---------- ------------------------ ---------- ----------------
395 31251 35298 0000000066E75338


Now enable autotrace in the original session:



SQL> set autotrace on


And the check the sessions again, from the other session:



SQL> select sid, process, port, paddr from v$session where username = 'BP';

SID PROCESS PORT PADDR
---------- ------------------------ ---------- ----------------
395 31251 35298 0000000066E75338
399 31251 35298 0000000066E75338

SQL> !sudo netstat -tanlp | grep 35298
tcp 0 0 127.0.0.1:35298 127.0.0.1:1521 ESTABLISHED 31251/sqlplus
tcp 0 0 127.0.0.1:1521 127.0.0.1:35298 ESTABLISHED 31253/oracleMIN18


We have 2 sessions, using the same client and server processes and the same TCP connection as well (and that is the usually surprising part). Now if we disconnect, but leave sqlplus running in the first session:



SQL> disconnect
Disconnected from Oracle Database 18c Enterprise Edition Release 18.0.0.0.0 - Production
Version 18.4.0.0.0
SQL>


And check the database again from the other session:



SQL> select sid, process, port, paddr from v$session where username = 'BP';

no rows selected

SQL> select spid from v$process where addr = '0000000066E75338';

SPID
------------------------
31253

SQL> !sudo netstat -tanlp | grep 35298
tcp 0 0 127.0.0.1:35298 127.0.0.1:1521 ESTABLISHED 31251/sqlplus
tcp 0 0 127.0.0.1:1521 127.0.0.1:35298 ESTABLISHED 31253/oracleMIN18

SQL> select sid, process, port, paddr from v$session where paddr = '0000000066E75338';

no rows selected


We still have the database server process, we still have the client process, we still have a TCP connection between them, but we have 0 sessions associated with them. Once you quit sqlplus with exit, that is when the processes and the connection terminate:



SQL> exit
[oracle@o71 ~]$


And:



SQL> select spid from v$process where addr = '0000000066E75338';

no rows selected

SQL> !sudo netstat -tanlp | grep 35298
tcp 0 0 127.0.0.1:35298 127.0.0.1:1521 TIME_WAIT -


So it is possible, but I have never seen this in practice apart from the above book and demos built based on it.






share|improve this answer





















    Your Answer








    StackExchange.ready(function() {
    var channelOptions = {
    tags: "".split(" "),
    id: "182"
    };
    initTagRenderer("".split(" "), "".split(" "), channelOptions);

    StackExchange.using("externalEditor", function() {
    // Have to fire editor after snippets, if snippets enabled
    if (StackExchange.settings.snippets.snippetsEnabled) {
    StackExchange.using("snippets", function() {
    createEditor();
    });
    }
    else {
    createEditor();
    }
    });

    function createEditor() {
    StackExchange.prepareEditor({
    heartbeatType: 'answer',
    autoActivateHeartbeat: false,
    convertImagesToLinks: false,
    noModals: true,
    showLowRepImageUploadWarning: true,
    reputationToPostImages: null,
    bindNavPrevention: true,
    postfix: "",
    imageUploader: {
    brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
    contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
    allowUrls: true
    },
    onDemand: true,
    discardSelector: ".discard-answer"
    ,immediatelyShowMarkdownHelp:true
    });


    }
    });






    Ashok Koyi is a new contributor. Be nice, and check out our Code of Conduct.










    draft saved

    draft discarded


















    StackExchange.ready(
    function () {
    StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fdba.stackexchange.com%2fquestions%2f225859%2fdatabase-connection-vs-raw-tcp-connection%23new-answer', 'question_page');
    }
    );

    Post as a guest















    Required, but never shown

























    3 Answers
    3






    active

    oldest

    votes








    3 Answers
    3






    active

    oldest

    votes









    active

    oldest

    votes






    active

    oldest

    votes









    9















    Do databases support multiple transactions simultaneously on a single database connection from client?




    For SQL Server, no.




    If not, why not? (as multiplexing would save on resource overhead per connection)




    It would seriously complicate the network protocol, which has to be implemented on multiple client platforms, creating a possible source of bugs and performance issues.



    And the resource overhead caused by multiple connections is small, and largely mitigated by connection pooling, where a set of long-lived connections is shared among all the threads in a client program.






    share|improve this answer























    • Assuming that you have thousands of simultaneous requests, wouldn't multiple requests compete for connections even in the pool? If simultaneous transactions are supported (I understand the complexity, but then non blocking IO is complex but servers do support it for performance reasons), we dont even need to worry about connection contention in pool & the performance should be much better than connection pools
      – Ashok Koyi
      13 hours ago








    • 4




      A TCP/IP connection is simply not an expensive enough resource to merit this design. The performance would probably not be "much better", and it might be worse as sessions would have to coordinate the utilization of the TCP/IP socket with other sessions wanting to read and write data.
      – David Browne - Microsoft
      12 hours ago










    • I've heard that postgres has a process/connection => a fixed overhead (~10MB) per connection, even if TCP connection overhead is small. Multiplexing looks to me like an attractive proposition there. Are there any downsides of multiplexing in that case?
      – Ashok Koyi
      12 hours ago












    • Right, but the costly thing is a session, not a network TCP/IP connection. Connection Pooling, and Application Server thread pools both enable "multiplexing", where 1000s of application users can share 10s of database sessions.
      – David Browne - Microsoft
      12 hours ago












    • But not simultaneously, is that correct?
      – Ashok Koyi
      12 hours ago
















    9















    Do databases support multiple transactions simultaneously on a single database connection from client?




    For SQL Server, no.




    If not, why not? (as multiplexing would save on resource overhead per connection)




    It would seriously complicate the network protocol, which has to be implemented on multiple client platforms, creating a possible source of bugs and performance issues.



    And the resource overhead caused by multiple connections is small, and largely mitigated by connection pooling, where a set of long-lived connections is shared among all the threads in a client program.






    share|improve this answer























    • Assuming that you have thousands of simultaneous requests, wouldn't multiple requests compete for connections even in the pool? If simultaneous transactions are supported (I understand the complexity, but then non blocking IO is complex but servers do support it for performance reasons), we dont even need to worry about connection contention in pool & the performance should be much better than connection pools
      – Ashok Koyi
      13 hours ago








    • 4




      A TCP/IP connection is simply not an expensive enough resource to merit this design. The performance would probably not be "much better", and it might be worse as sessions would have to coordinate the utilization of the TCP/IP socket with other sessions wanting to read and write data.
      – David Browne - Microsoft
      12 hours ago










    • I've heard that postgres has a process/connection => a fixed overhead (~10MB) per connection, even if TCP connection overhead is small. Multiplexing looks to me like an attractive proposition there. Are there any downsides of multiplexing in that case?
      – Ashok Koyi
      12 hours ago












    • Right, but the costly thing is a session, not a network TCP/IP connection. Connection Pooling, and Application Server thread pools both enable "multiplexing", where 1000s of application users can share 10s of database sessions.
      – David Browne - Microsoft
      12 hours ago












    • But not simultaneously, is that correct?
      – Ashok Koyi
      12 hours ago














    9












    9








    9







    Do databases support multiple transactions simultaneously on a single database connection from client?




    For SQL Server, no.




    If not, why not? (as multiplexing would save on resource overhead per connection)




    It would seriously complicate the network protocol, which has to be implemented on multiple client platforms, creating a possible source of bugs and performance issues.



    And the resource overhead caused by multiple connections is small, and largely mitigated by connection pooling, where a set of long-lived connections is shared among all the threads in a client program.






    share|improve this answer















    Do databases support multiple transactions simultaneously on a single database connection from client?




    For SQL Server, no.




    If not, why not? (as multiplexing would save on resource overhead per connection)




    It would seriously complicate the network protocol, which has to be implemented on multiple client platforms, creating a possible source of bugs and performance issues.



    And the resource overhead caused by multiple connections is small, and largely mitigated by connection pooling, where a set of long-lived connections is shared among all the threads in a client program.







    share|improve this answer














    share|improve this answer



    share|improve this answer








    edited 14 hours ago

























    answered 14 hours ago









    David Browne - Microsoft

    10.4k725




    10.4k725












    • Assuming that you have thousands of simultaneous requests, wouldn't multiple requests compete for connections even in the pool? If simultaneous transactions are supported (I understand the complexity, but then non blocking IO is complex but servers do support it for performance reasons), we dont even need to worry about connection contention in pool & the performance should be much better than connection pools
      – Ashok Koyi
      13 hours ago








    • 4




      A TCP/IP connection is simply not an expensive enough resource to merit this design. The performance would probably not be "much better", and it might be worse as sessions would have to coordinate the utilization of the TCP/IP socket with other sessions wanting to read and write data.
      – David Browne - Microsoft
      12 hours ago










    • I've heard that postgres has a process/connection => a fixed overhead (~10MB) per connection, even if TCP connection overhead is small. Multiplexing looks to me like an attractive proposition there. Are there any downsides of multiplexing in that case?
      – Ashok Koyi
      12 hours ago












    • Right, but the costly thing is a session, not a network TCP/IP connection. Connection Pooling, and Application Server thread pools both enable "multiplexing", where 1000s of application users can share 10s of database sessions.
      – David Browne - Microsoft
      12 hours ago












    • But not simultaneously, is that correct?
      – Ashok Koyi
      12 hours ago


















    • Assuming that you have thousands of simultaneous requests, wouldn't multiple requests compete for connections even in the pool? If simultaneous transactions are supported (I understand the complexity, but then non blocking IO is complex but servers do support it for performance reasons), we dont even need to worry about connection contention in pool & the performance should be much better than connection pools
      – Ashok Koyi
      13 hours ago








    • 4




      A TCP/IP connection is simply not an expensive enough resource to merit this design. The performance would probably not be "much better", and it might be worse as sessions would have to coordinate the utilization of the TCP/IP socket with other sessions wanting to read and write data.
      – David Browne - Microsoft
      12 hours ago










    • I've heard that postgres has a process/connection => a fixed overhead (~10MB) per connection, even if TCP connection overhead is small. Multiplexing looks to me like an attractive proposition there. Are there any downsides of multiplexing in that case?
      – Ashok Koyi
      12 hours ago












    • Right, but the costly thing is a session, not a network TCP/IP connection. Connection Pooling, and Application Server thread pools both enable "multiplexing", where 1000s of application users can share 10s of database sessions.
      – David Browne - Microsoft
      12 hours ago












    • But not simultaneously, is that correct?
      – Ashok Koyi
      12 hours ago
















    Assuming that you have thousands of simultaneous requests, wouldn't multiple requests compete for connections even in the pool? If simultaneous transactions are supported (I understand the complexity, but then non blocking IO is complex but servers do support it for performance reasons), we dont even need to worry about connection contention in pool & the performance should be much better than connection pools
    – Ashok Koyi
    13 hours ago






    Assuming that you have thousands of simultaneous requests, wouldn't multiple requests compete for connections even in the pool? If simultaneous transactions are supported (I understand the complexity, but then non blocking IO is complex but servers do support it for performance reasons), we dont even need to worry about connection contention in pool & the performance should be much better than connection pools
    – Ashok Koyi
    13 hours ago






    4




    4




    A TCP/IP connection is simply not an expensive enough resource to merit this design. The performance would probably not be "much better", and it might be worse as sessions would have to coordinate the utilization of the TCP/IP socket with other sessions wanting to read and write data.
    – David Browne - Microsoft
    12 hours ago




    A TCP/IP connection is simply not an expensive enough resource to merit this design. The performance would probably not be "much better", and it might be worse as sessions would have to coordinate the utilization of the TCP/IP socket with other sessions wanting to read and write data.
    – David Browne - Microsoft
    12 hours ago












    I've heard that postgres has a process/connection => a fixed overhead (~10MB) per connection, even if TCP connection overhead is small. Multiplexing looks to me like an attractive proposition there. Are there any downsides of multiplexing in that case?
    – Ashok Koyi
    12 hours ago






    I've heard that postgres has a process/connection => a fixed overhead (~10MB) per connection, even if TCP connection overhead is small. Multiplexing looks to me like an attractive proposition there. Are there any downsides of multiplexing in that case?
    – Ashok Koyi
    12 hours ago














    Right, but the costly thing is a session, not a network TCP/IP connection. Connection Pooling, and Application Server thread pools both enable "multiplexing", where 1000s of application users can share 10s of database sessions.
    – David Browne - Microsoft
    12 hours ago






    Right, but the costly thing is a session, not a network TCP/IP connection. Connection Pooling, and Application Server thread pools both enable "multiplexing", where 1000s of application users can share 10s of database sessions.
    – David Browne - Microsoft
    12 hours ago














    But not simultaneously, is that correct?
    – Ashok Koyi
    12 hours ago




    But not simultaneously, is that correct?
    – Ashok Koyi
    12 hours ago













    2














    The parallelism you hint at in Q1 is oversold. Even when you can do things in parallel, the system bogs down for many reasons:




    • Hit a brick wall of some resource: CPU / Network / Disk I/O / etc.

    • There will be "critical sections" and other interlocks to prevent stepping on each other. For "a few" connections / transactions / etc, this is not a big deal. But even at a few dozen, the system begins to noticeably stumble over itself.

    • Some multi-threaded applications hit an algorithm brick wall. Sorting is a classic example. Maybe you can launch a hundred threads (and get nearly a hundred-fold speedup) to compute the items in a big list, but if you need the resultset to be sorted, the application will not be able to get anywhere near the hundred-fold speedup in that phase. And then you have to funnel all the data into a single stream for delivering!


    Databases are easier to design if you stop with the necessary requirement: separate clients must not step on each other. Then, within a single client, it is easier to focus on doing one thing at a time.



    Learn about KISS.



    As for the TCP layer -- You have the opportunity to design a router that can achieve what you suggest. You could make millions. But it belongs at a low level, not in the database engine.






    share|improve this answer





















    • You are making multiple assumptions about the usecases here. Everything you said is equally applicable whether the connection is multiplexed (or) not. I'm talking from the point of view of fundamentals of what an ideal database client should look like. The resource utilisation is there whether you have multiplexed/non multiplexed transactions. But the non-multiplexed are always costly as each connection has a fixed overhead (incase of postgres a process/connection=~10MB space). Non blocking IO does not follow KISS (as its quite complex), yet all performance critical applications use it
      – Ashok Koyi
      12 hours ago
















    2














    The parallelism you hint at in Q1 is oversold. Even when you can do things in parallel, the system bogs down for many reasons:




    • Hit a brick wall of some resource: CPU / Network / Disk I/O / etc.

    • There will be "critical sections" and other interlocks to prevent stepping on each other. For "a few" connections / transactions / etc, this is not a big deal. But even at a few dozen, the system begins to noticeably stumble over itself.

    • Some multi-threaded applications hit an algorithm brick wall. Sorting is a classic example. Maybe you can launch a hundred threads (and get nearly a hundred-fold speedup) to compute the items in a big list, but if you need the resultset to be sorted, the application will not be able to get anywhere near the hundred-fold speedup in that phase. And then you have to funnel all the data into a single stream for delivering!


    Databases are easier to design if you stop with the necessary requirement: separate clients must not step on each other. Then, within a single client, it is easier to focus on doing one thing at a time.



    Learn about KISS.



    As for the TCP layer -- You have the opportunity to design a router that can achieve what you suggest. You could make millions. But it belongs at a low level, not in the database engine.






    share|improve this answer





















    • You are making multiple assumptions about the usecases here. Everything you said is equally applicable whether the connection is multiplexed (or) not. I'm talking from the point of view of fundamentals of what an ideal database client should look like. The resource utilisation is there whether you have multiplexed/non multiplexed transactions. But the non-multiplexed are always costly as each connection has a fixed overhead (incase of postgres a process/connection=~10MB space). Non blocking IO does not follow KISS (as its quite complex), yet all performance critical applications use it
      – Ashok Koyi
      12 hours ago














    2












    2








    2






    The parallelism you hint at in Q1 is oversold. Even when you can do things in parallel, the system bogs down for many reasons:




    • Hit a brick wall of some resource: CPU / Network / Disk I/O / etc.

    • There will be "critical sections" and other interlocks to prevent stepping on each other. For "a few" connections / transactions / etc, this is not a big deal. But even at a few dozen, the system begins to noticeably stumble over itself.

    • Some multi-threaded applications hit an algorithm brick wall. Sorting is a classic example. Maybe you can launch a hundred threads (and get nearly a hundred-fold speedup) to compute the items in a big list, but if you need the resultset to be sorted, the application will not be able to get anywhere near the hundred-fold speedup in that phase. And then you have to funnel all the data into a single stream for delivering!


    Databases are easier to design if you stop with the necessary requirement: separate clients must not step on each other. Then, within a single client, it is easier to focus on doing one thing at a time.



    Learn about KISS.



    As for the TCP layer -- You have the opportunity to design a router that can achieve what you suggest. You could make millions. But it belongs at a low level, not in the database engine.






    share|improve this answer












    The parallelism you hint at in Q1 is oversold. Even when you can do things in parallel, the system bogs down for many reasons:




    • Hit a brick wall of some resource: CPU / Network / Disk I/O / etc.

    • There will be "critical sections" and other interlocks to prevent stepping on each other. For "a few" connections / transactions / etc, this is not a big deal. But even at a few dozen, the system begins to noticeably stumble over itself.

    • Some multi-threaded applications hit an algorithm brick wall. Sorting is a classic example. Maybe you can launch a hundred threads (and get nearly a hundred-fold speedup) to compute the items in a big list, but if you need the resultset to be sorted, the application will not be able to get anywhere near the hundred-fold speedup in that phase. And then you have to funnel all the data into a single stream for delivering!


    Databases are easier to design if you stop with the necessary requirement: separate clients must not step on each other. Then, within a single client, it is easier to focus on doing one thing at a time.



    Learn about KISS.



    As for the TCP layer -- You have the opportunity to design a router that can achieve what you suggest. You could make millions. But it belongs at a low level, not in the database engine.







    share|improve this answer












    share|improve this answer



    share|improve this answer










    answered 13 hours ago









    Rick James

    40.6k22257




    40.6k22257












    • You are making multiple assumptions about the usecases here. Everything you said is equally applicable whether the connection is multiplexed (or) not. I'm talking from the point of view of fundamentals of what an ideal database client should look like. The resource utilisation is there whether you have multiplexed/non multiplexed transactions. But the non-multiplexed are always costly as each connection has a fixed overhead (incase of postgres a process/connection=~10MB space). Non blocking IO does not follow KISS (as its quite complex), yet all performance critical applications use it
      – Ashok Koyi
      12 hours ago


















    • You are making multiple assumptions about the usecases here. Everything you said is equally applicable whether the connection is multiplexed (or) not. I'm talking from the point of view of fundamentals of what an ideal database client should look like. The resource utilisation is there whether you have multiplexed/non multiplexed transactions. But the non-multiplexed are always costly as each connection has a fixed overhead (incase of postgres a process/connection=~10MB space). Non blocking IO does not follow KISS (as its quite complex), yet all performance critical applications use it
      – Ashok Koyi
      12 hours ago
















    You are making multiple assumptions about the usecases here. Everything you said is equally applicable whether the connection is multiplexed (or) not. I'm talking from the point of view of fundamentals of what an ideal database client should look like. The resource utilisation is there whether you have multiplexed/non multiplexed transactions. But the non-multiplexed are always costly as each connection has a fixed overhead (incase of postgres a process/connection=~10MB space). Non blocking IO does not follow KISS (as its quite complex), yet all performance critical applications use it
    – Ashok Koyi
    12 hours ago




    You are making multiple assumptions about the usecases here. Everything you said is equally applicable whether the connection is multiplexed (or) not. I'm talking from the point of view of fundamentals of what an ideal database client should look like. The resource utilisation is there whether you have multiplexed/non multiplexed transactions. But the non-multiplexed are always costly as each connection has a fixed overhead (incase of postgres a process/connection=~10MB space). Non blocking IO does not follow KISS (as its quite complex), yet all performance critical applications use it
    – Ashok Koyi
    12 hours ago











    2














    Oracle



    It is a little-known fact, that in Oracle, one can have 0, 1 or even more sessions in the very same TCP connection.



    This is discussed in the book Expert Oracle Database Architecture (ISBN 978-1-4302-6299-2, Authors: Kyte, Thomas, Kuhn, Darl) in Chapter 5 - Oracle Processes.



    https://books.google.com/books?id=NG4RpD8aLEIC&pg=PA170




    Connections vs. Sessions



    It surprises many people to discover that a
    connection is not synonymous with a session. In most people’s eyes
    they are the same, but the reality is they do not have to be. A
    connection may have zero, one, or more sessions established on it.
    Each session is separate and independent, even though they all share
    the same physical connection to the database. A commit in one session
    does not affect any other session on that connection. In fact, each
    session using that connection could use different user identities!
    In
    Oracle, a connection is simply a physical circuit between your client
    process and the database instance — a network connection, most
    commonly. The connection may be to a dedicated server process or to a
    dispatcher. As previously stated, a connection may have zero or more
    sessions, meaning that a connection may exist with no corresponding
    sessions.




    Demo:



    Log in to the database:



    [oracle@o71 ~]$ sqlplus bp/bp@'localhost:1521/min18'

    SQL*Plus: Release 18.0.0.0.0 - Production on Thu Dec 27 21:20:03 2018
    Version 18.4.0.0.0

    Copyright (c) 1982, 2018, Oracle. All rights reserved.

    Last Successful login time: Thu Dec 27 2018 21:07:47 +01:00

    Connected to:
    Oracle Database 18c Enterprise Edition Release 18.0.0.0.0 - Production
    Version 18.4.0.0.0

    SQL>


    In another session, started somewhere else, query the sessions of BP:



    SQL> select sid, process, port, paddr from v$session where username = 'BP';

    SID PROCESS PORT PADDR
    ---------- ------------------------ ---------- ----------------
    395 31251 35298 0000000066E75338


    Now enable autotrace in the original session:



    SQL> set autotrace on


    And the check the sessions again, from the other session:



    SQL> select sid, process, port, paddr from v$session where username = 'BP';

    SID PROCESS PORT PADDR
    ---------- ------------------------ ---------- ----------------
    395 31251 35298 0000000066E75338
    399 31251 35298 0000000066E75338

    SQL> !sudo netstat -tanlp | grep 35298
    tcp 0 0 127.0.0.1:35298 127.0.0.1:1521 ESTABLISHED 31251/sqlplus
    tcp 0 0 127.0.0.1:1521 127.0.0.1:35298 ESTABLISHED 31253/oracleMIN18


    We have 2 sessions, using the same client and server processes and the same TCP connection as well (and that is the usually surprising part). Now if we disconnect, but leave sqlplus running in the first session:



    SQL> disconnect
    Disconnected from Oracle Database 18c Enterprise Edition Release 18.0.0.0.0 - Production
    Version 18.4.0.0.0
    SQL>


    And check the database again from the other session:



    SQL> select sid, process, port, paddr from v$session where username = 'BP';

    no rows selected

    SQL> select spid from v$process where addr = '0000000066E75338';

    SPID
    ------------------------
    31253

    SQL> !sudo netstat -tanlp | grep 35298
    tcp 0 0 127.0.0.1:35298 127.0.0.1:1521 ESTABLISHED 31251/sqlplus
    tcp 0 0 127.0.0.1:1521 127.0.0.1:35298 ESTABLISHED 31253/oracleMIN18

    SQL> select sid, process, port, paddr from v$session where paddr = '0000000066E75338';

    no rows selected


    We still have the database server process, we still have the client process, we still have a TCP connection between them, but we have 0 sessions associated with them. Once you quit sqlplus with exit, that is when the processes and the connection terminate:



    SQL> exit
    [oracle@o71 ~]$


    And:



    SQL> select spid from v$process where addr = '0000000066E75338';

    no rows selected

    SQL> !sudo netstat -tanlp | grep 35298
    tcp 0 0 127.0.0.1:35298 127.0.0.1:1521 TIME_WAIT -


    So it is possible, but I have never seen this in practice apart from the above book and demos built based on it.






    share|improve this answer


























      2














      Oracle



      It is a little-known fact, that in Oracle, one can have 0, 1 or even more sessions in the very same TCP connection.



      This is discussed in the book Expert Oracle Database Architecture (ISBN 978-1-4302-6299-2, Authors: Kyte, Thomas, Kuhn, Darl) in Chapter 5 - Oracle Processes.



      https://books.google.com/books?id=NG4RpD8aLEIC&pg=PA170




      Connections vs. Sessions



      It surprises many people to discover that a
      connection is not synonymous with a session. In most people’s eyes
      they are the same, but the reality is they do not have to be. A
      connection may have zero, one, or more sessions established on it.
      Each session is separate and independent, even though they all share
      the same physical connection to the database. A commit in one session
      does not affect any other session on that connection. In fact, each
      session using that connection could use different user identities!
      In
      Oracle, a connection is simply a physical circuit between your client
      process and the database instance — a network connection, most
      commonly. The connection may be to a dedicated server process or to a
      dispatcher. As previously stated, a connection may have zero or more
      sessions, meaning that a connection may exist with no corresponding
      sessions.




      Demo:



      Log in to the database:



      [oracle@o71 ~]$ sqlplus bp/bp@'localhost:1521/min18'

      SQL*Plus: Release 18.0.0.0.0 - Production on Thu Dec 27 21:20:03 2018
      Version 18.4.0.0.0

      Copyright (c) 1982, 2018, Oracle. All rights reserved.

      Last Successful login time: Thu Dec 27 2018 21:07:47 +01:00

      Connected to:
      Oracle Database 18c Enterprise Edition Release 18.0.0.0.0 - Production
      Version 18.4.0.0.0

      SQL>


      In another session, started somewhere else, query the sessions of BP:



      SQL> select sid, process, port, paddr from v$session where username = 'BP';

      SID PROCESS PORT PADDR
      ---------- ------------------------ ---------- ----------------
      395 31251 35298 0000000066E75338


      Now enable autotrace in the original session:



      SQL> set autotrace on


      And the check the sessions again, from the other session:



      SQL> select sid, process, port, paddr from v$session where username = 'BP';

      SID PROCESS PORT PADDR
      ---------- ------------------------ ---------- ----------------
      395 31251 35298 0000000066E75338
      399 31251 35298 0000000066E75338

      SQL> !sudo netstat -tanlp | grep 35298
      tcp 0 0 127.0.0.1:35298 127.0.0.1:1521 ESTABLISHED 31251/sqlplus
      tcp 0 0 127.0.0.1:1521 127.0.0.1:35298 ESTABLISHED 31253/oracleMIN18


      We have 2 sessions, using the same client and server processes and the same TCP connection as well (and that is the usually surprising part). Now if we disconnect, but leave sqlplus running in the first session:



      SQL> disconnect
      Disconnected from Oracle Database 18c Enterprise Edition Release 18.0.0.0.0 - Production
      Version 18.4.0.0.0
      SQL>


      And check the database again from the other session:



      SQL> select sid, process, port, paddr from v$session where username = 'BP';

      no rows selected

      SQL> select spid from v$process where addr = '0000000066E75338';

      SPID
      ------------------------
      31253

      SQL> !sudo netstat -tanlp | grep 35298
      tcp 0 0 127.0.0.1:35298 127.0.0.1:1521 ESTABLISHED 31251/sqlplus
      tcp 0 0 127.0.0.1:1521 127.0.0.1:35298 ESTABLISHED 31253/oracleMIN18

      SQL> select sid, process, port, paddr from v$session where paddr = '0000000066E75338';

      no rows selected


      We still have the database server process, we still have the client process, we still have a TCP connection between them, but we have 0 sessions associated with them. Once you quit sqlplus with exit, that is when the processes and the connection terminate:



      SQL> exit
      [oracle@o71 ~]$


      And:



      SQL> select spid from v$process where addr = '0000000066E75338';

      no rows selected

      SQL> !sudo netstat -tanlp | grep 35298
      tcp 0 0 127.0.0.1:35298 127.0.0.1:1521 TIME_WAIT -


      So it is possible, but I have never seen this in practice apart from the above book and demos built based on it.






      share|improve this answer
























        2












        2








        2






        Oracle



        It is a little-known fact, that in Oracle, one can have 0, 1 or even more sessions in the very same TCP connection.



        This is discussed in the book Expert Oracle Database Architecture (ISBN 978-1-4302-6299-2, Authors: Kyte, Thomas, Kuhn, Darl) in Chapter 5 - Oracle Processes.



        https://books.google.com/books?id=NG4RpD8aLEIC&pg=PA170




        Connections vs. Sessions



        It surprises many people to discover that a
        connection is not synonymous with a session. In most people’s eyes
        they are the same, but the reality is they do not have to be. A
        connection may have zero, one, or more sessions established on it.
        Each session is separate and independent, even though they all share
        the same physical connection to the database. A commit in one session
        does not affect any other session on that connection. In fact, each
        session using that connection could use different user identities!
        In
        Oracle, a connection is simply a physical circuit between your client
        process and the database instance — a network connection, most
        commonly. The connection may be to a dedicated server process or to a
        dispatcher. As previously stated, a connection may have zero or more
        sessions, meaning that a connection may exist with no corresponding
        sessions.




        Demo:



        Log in to the database:



        [oracle@o71 ~]$ sqlplus bp/bp@'localhost:1521/min18'

        SQL*Plus: Release 18.0.0.0.0 - Production on Thu Dec 27 21:20:03 2018
        Version 18.4.0.0.0

        Copyright (c) 1982, 2018, Oracle. All rights reserved.

        Last Successful login time: Thu Dec 27 2018 21:07:47 +01:00

        Connected to:
        Oracle Database 18c Enterprise Edition Release 18.0.0.0.0 - Production
        Version 18.4.0.0.0

        SQL>


        In another session, started somewhere else, query the sessions of BP:



        SQL> select sid, process, port, paddr from v$session where username = 'BP';

        SID PROCESS PORT PADDR
        ---------- ------------------------ ---------- ----------------
        395 31251 35298 0000000066E75338


        Now enable autotrace in the original session:



        SQL> set autotrace on


        And the check the sessions again, from the other session:



        SQL> select sid, process, port, paddr from v$session where username = 'BP';

        SID PROCESS PORT PADDR
        ---------- ------------------------ ---------- ----------------
        395 31251 35298 0000000066E75338
        399 31251 35298 0000000066E75338

        SQL> !sudo netstat -tanlp | grep 35298
        tcp 0 0 127.0.0.1:35298 127.0.0.1:1521 ESTABLISHED 31251/sqlplus
        tcp 0 0 127.0.0.1:1521 127.0.0.1:35298 ESTABLISHED 31253/oracleMIN18


        We have 2 sessions, using the same client and server processes and the same TCP connection as well (and that is the usually surprising part). Now if we disconnect, but leave sqlplus running in the first session:



        SQL> disconnect
        Disconnected from Oracle Database 18c Enterprise Edition Release 18.0.0.0.0 - Production
        Version 18.4.0.0.0
        SQL>


        And check the database again from the other session:



        SQL> select sid, process, port, paddr from v$session where username = 'BP';

        no rows selected

        SQL> select spid from v$process where addr = '0000000066E75338';

        SPID
        ------------------------
        31253

        SQL> !sudo netstat -tanlp | grep 35298
        tcp 0 0 127.0.0.1:35298 127.0.0.1:1521 ESTABLISHED 31251/sqlplus
        tcp 0 0 127.0.0.1:1521 127.0.0.1:35298 ESTABLISHED 31253/oracleMIN18

        SQL> select sid, process, port, paddr from v$session where paddr = '0000000066E75338';

        no rows selected


        We still have the database server process, we still have the client process, we still have a TCP connection between them, but we have 0 sessions associated with them. Once you quit sqlplus with exit, that is when the processes and the connection terminate:



        SQL> exit
        [oracle@o71 ~]$


        And:



        SQL> select spid from v$process where addr = '0000000066E75338';

        no rows selected

        SQL> !sudo netstat -tanlp | grep 35298
        tcp 0 0 127.0.0.1:35298 127.0.0.1:1521 TIME_WAIT -


        So it is possible, but I have never seen this in practice apart from the above book and demos built based on it.






        share|improve this answer












        Oracle



        It is a little-known fact, that in Oracle, one can have 0, 1 or even more sessions in the very same TCP connection.



        This is discussed in the book Expert Oracle Database Architecture (ISBN 978-1-4302-6299-2, Authors: Kyte, Thomas, Kuhn, Darl) in Chapter 5 - Oracle Processes.



        https://books.google.com/books?id=NG4RpD8aLEIC&pg=PA170




        Connections vs. Sessions



        It surprises many people to discover that a
        connection is not synonymous with a session. In most people’s eyes
        they are the same, but the reality is they do not have to be. A
        connection may have zero, one, or more sessions established on it.
        Each session is separate and independent, even though they all share
        the same physical connection to the database. A commit in one session
        does not affect any other session on that connection. In fact, each
        session using that connection could use different user identities!
        In
        Oracle, a connection is simply a physical circuit between your client
        process and the database instance — a network connection, most
        commonly. The connection may be to a dedicated server process or to a
        dispatcher. As previously stated, a connection may have zero or more
        sessions, meaning that a connection may exist with no corresponding
        sessions.




        Demo:



        Log in to the database:



        [oracle@o71 ~]$ sqlplus bp/bp@'localhost:1521/min18'

        SQL*Plus: Release 18.0.0.0.0 - Production on Thu Dec 27 21:20:03 2018
        Version 18.4.0.0.0

        Copyright (c) 1982, 2018, Oracle. All rights reserved.

        Last Successful login time: Thu Dec 27 2018 21:07:47 +01:00

        Connected to:
        Oracle Database 18c Enterprise Edition Release 18.0.0.0.0 - Production
        Version 18.4.0.0.0

        SQL>


        In another session, started somewhere else, query the sessions of BP:



        SQL> select sid, process, port, paddr from v$session where username = 'BP';

        SID PROCESS PORT PADDR
        ---------- ------------------------ ---------- ----------------
        395 31251 35298 0000000066E75338


        Now enable autotrace in the original session:



        SQL> set autotrace on


        And the check the sessions again, from the other session:



        SQL> select sid, process, port, paddr from v$session where username = 'BP';

        SID PROCESS PORT PADDR
        ---------- ------------------------ ---------- ----------------
        395 31251 35298 0000000066E75338
        399 31251 35298 0000000066E75338

        SQL> !sudo netstat -tanlp | grep 35298
        tcp 0 0 127.0.0.1:35298 127.0.0.1:1521 ESTABLISHED 31251/sqlplus
        tcp 0 0 127.0.0.1:1521 127.0.0.1:35298 ESTABLISHED 31253/oracleMIN18


        We have 2 sessions, using the same client and server processes and the same TCP connection as well (and that is the usually surprising part). Now if we disconnect, but leave sqlplus running in the first session:



        SQL> disconnect
        Disconnected from Oracle Database 18c Enterprise Edition Release 18.0.0.0.0 - Production
        Version 18.4.0.0.0
        SQL>


        And check the database again from the other session:



        SQL> select sid, process, port, paddr from v$session where username = 'BP';

        no rows selected

        SQL> select spid from v$process where addr = '0000000066E75338';

        SPID
        ------------------------
        31253

        SQL> !sudo netstat -tanlp | grep 35298
        tcp 0 0 127.0.0.1:35298 127.0.0.1:1521 ESTABLISHED 31251/sqlplus
        tcp 0 0 127.0.0.1:1521 127.0.0.1:35298 ESTABLISHED 31253/oracleMIN18

        SQL> select sid, process, port, paddr from v$session where paddr = '0000000066E75338';

        no rows selected


        We still have the database server process, we still have the client process, we still have a TCP connection between them, but we have 0 sessions associated with them. Once you quit sqlplus with exit, that is when the processes and the connection terminate:



        SQL> exit
        [oracle@o71 ~]$


        And:



        SQL> select spid from v$process where addr = '0000000066E75338';

        no rows selected

        SQL> !sudo netstat -tanlp | grep 35298
        tcp 0 0 127.0.0.1:35298 127.0.0.1:1521 TIME_WAIT -


        So it is possible, but I have never seen this in practice apart from the above book and demos built based on it.







        share|improve this answer












        share|improve this answer



        share|improve this answer










        answered 10 hours ago









        Balazs Papp

        25.1k2930




        25.1k2930






















            Ashok Koyi is a new contributor. Be nice, and check out our Code of Conduct.










            draft saved

            draft discarded


















            Ashok Koyi is a new contributor. Be nice, and check out our Code of Conduct.













            Ashok Koyi is a new contributor. Be nice, and check out our Code of Conduct.












            Ashok Koyi is a new contributor. Be nice, and check out our Code of Conduct.
















            Thanks for contributing an answer to Database Administrators Stack Exchange!


            • Please be sure to answer the question. Provide details and share your research!

            But avoid



            • Asking for help, clarification, or responding to other answers.

            • Making statements based on opinion; back them up with references or personal experience.


            To learn more, see our tips on writing great answers.





            Some of your past answers have not been well-received, and you're in danger of being blocked from answering.


            Please pay close attention to the following guidance:


            • Please be sure to answer the question. Provide details and share your research!

            But avoid



            • Asking for help, clarification, or responding to other answers.

            • Making statements based on opinion; back them up with references or personal experience.


            To learn more, see our tips on writing great answers.




            draft saved


            draft discarded














            StackExchange.ready(
            function () {
            StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fdba.stackexchange.com%2fquestions%2f225859%2fdatabase-connection-vs-raw-tcp-connection%23new-answer', 'question_page');
            }
            );

            Post as a guest















            Required, but never shown





















































            Required, but never shown














            Required, but never shown












            Required, but never shown







            Required, but never shown

































            Required, but never shown














            Required, but never shown












            Required, but never shown







            Required, but never shown







            Popular posts from this blog

            數位音樂下載

            When can things happen in Etherscan, such as the picture below?

            格利澤436b