exasol / exasol-driver-ts

Exasol Typescript / Javascript Driver for Node and the Browser
MIT License
0 stars 1 forks source link

Allow more than 1 connection in the connection pool #28

Open espenhogbakk opened 1 month ago

espenhogbakk commented 1 month ago

It seems like this driver only supports 1 connection in a connection pool. I can see there are some tests and code related to multiple connections in a pool. but when initializing the driver, it uses a hardcoded value of 1 when it creates the pool.

Is there any particular reason we can't use a large pool size?

kaklakariada commented 1 month ago

Hi @espenhogbakk, thank you for your feature request. While it should be easy to implement we need to add documentation and integration tests to verify it really works. Our product manager put it onto the roadmap but we don't know when it will be implemented.

espenhogbakk commented 1 month ago

Thanks for the response.

So am I correct in thinking the only way to reliably use this driver now is to do this for every query?

driver.connect()
driver.query()
driver.close()

Unless of course you in the same "context" are doing multiple queries in series (and don't want to do them in parallell). E.g in our Node.js application we might get a bunch of requests in at the same time, handled in different contexts/processes and then without a connection pool we need to establish a new connection to the cluster, query and close it down?

Seems like there is quite a bit overhead of doing so, see this log output

[2024-05-27T21:41:02.202Z] DEBUG: [SQLClient] Login
[2024-05-27T21:41:02.203Z] DEBUG: [Pool:1716846061955] Add connection
[2024-05-27T21:41:02.204Z] DEBUG: [Pool:1716846061955] Assign connection
[2024-05-27T21:41:02.267Z] DEBUG: [Connection:1716846061955] Received data
[2024-05-27T21:41:02.267Z] DEBUG: [Pool:1716846061955] Release connection
[2024-05-27T21:41:02.288Z] DEBUG: [Pool:1716846061955] Assign connection
[2024-05-27T21:41:02.977Z] DEBUG: [Connection:1716846061955] Received data
[2024-05-27T21:41:02.977Z] DEBUG: [Pool:1716846061955] Release connection
[2024-05-27T21:41:02.978Z] DEBUG: [Pool:1716846061955] Assign connection
[2024-05-27T21:41:03.104Z] DEBUG: [Connection:1716846061955] Received data
[2024-05-27T21:41:03.105Z] DEBUG: [WebSQL]: Fetch more data for:  1
[2024-05-27T21:41:03.106Z] DEBUG: [WebSQL]: fetchMoreData: 0 13146
[2024-05-27T21:41:03.154Z] DEBUG: [Connection:1716846061955] Received data
...
[2024-05-27T21:41:08.579Z] DEBUG: [WebSQL]: fetchMoreData: 13144 13146
[2024-05-27T21:41:08.646Z] DEBUG: [Connection:1716846061955] Received data
[2024-05-27T21:41:08.648Z] DEBUG: [WebSQL]: Closing ResultSet 1
[2024-05-27T21:41:08.652Z] DEBUG: [WebSQL]: Loaded all data
[2024-05-27T21:41:08.653Z] DEBUG: [Pool:1716846061955] Release connection
[2024-05-27T21:41:08.663Z] DEBUG: [SQLClient] Close all connections

That is 902ms before we receive any data. I must be missing something as this surely isn't how it's supposed to be?

kaklakariada commented 1 month ago

I am not very familiar with the code, but I don't think there is another way, unless you implement a connection pool in your application :-( I will ask our product manager to prioritize this.