The approaches described in this section are approaches that could be pursued, but not necessarily approaches that have been previously conceived or pursued. Therefore, unless otherwise indicated, it should not be assumed that any of the approaches described in this section qualify as prior art merely by virtue of their inclusion in this section.
Traditionally a programmatic connection between a client computer system and a database management system (DBMS) is established using a streaming protocol. For example, the most basic streaming protocol is Transmission Control Protocol complemented with Internet Protocol (TCP/IP). In such a protocol, a client computer system and a server system, such as a DBMS, open up sockets at a particular port on respective network controllers and communicate via streams of data. For example, Open Database Connectivity (ODBC) and Java Database Connectivity (JDBC), which define application programming interface based drivers for communicating with a DBMS, mainly use TCP streaming for the underlying communication with the DBMS.
However, a stream based connection poses a great challenge for the computer infrastructure hosting a DBMS. For example, stream-based ODBC and JDBC drivers provide little flexibility to route the connection to different servers for load balancing. Once the streaming connection between an ODBC or a JDBC driver on a client computer system and a particular database server of DBMS is established, there is no easy way to re-direct or route this connection to another database server without interrupting the connection's persistency, which is required for stream-based connections. Accordingly, the computer infrastructure hosting the DBMS has to rely only on the DBMS's internal load balancing or fail-over algorithms to ensure resilience. However, the DBMS's internal fail-over may not be effective when a connection to the DBMS itself is interrupted. Furthermore, the DBMS's load balancing often hinges on the resource consumption of query executions internal to the DBMS, which may not provide effective resource distribution across all connections to the DBMS. A connection level load balancing would be preferred in addition or alternative to the DBMS's own load balancing.
Furthermore, any network interruption may severely affect a stream-based connection utilized by ODBC or JDBC drivers. Stream-based communications heavily rely on the assumption that the continuity of connection(s) will be maintained until graceful disconnection by the participating client(s) or server(s). Accordingly, when a data stream is interrupted due to a network connection interruption or for any other reason, the client and the server of the interrupted connection have to cycle through number of steps, particularly re-establishing the states of receipt and/or transmission of the data in the stream up to the interruption of the connection, and re-establishing the connection sockets to reconnect the client and server. That may be a complex task and require intricate state management on the server and/or client side.
Additionally, TCP/IP-based connections by ODBC/JDBC drivers utilize ports that are usually closed in most corporate firewalls and even by whole countries. Thus, a client computer system trying to connect from outside a corporate network using a TCP/IP-based connection may fail to establish communication to the server beyond the firewall. Similarly, a client computer within a corporate network may fail to connect to a server outside of the corporate network using a TCP/IP-based connection. A traditional work around to allow ODBC/JDBC drivers to communicate across the firewalls is to add exceptions for the ODBC/JDBC ports. However, in addition to being a manual process, certain entities that maintain firewalls have strict policies that may not allow the opening of such ports.
USPTO Backgrounds
USPTO Backgrounds