introduce "sticky session" concept for handling temporary tables #381
Open
Description
Use case
Today, things like temporary tables rely on the same connection to operate. To ensure that today, we need to ensure we start the clickhouse client with max_open_connections: 1
as per the docs, but that means down our application stack we need to keep 2 versions of clickhouse client:
- one for the default connection pool
- one that is a constructor to starting a new clickhouse client with
max_open_connections = 1
and a fixed sticky session.
Describe the solution you'd like
This takes inspiration from the database/sql
Golang package and how they handle transactions.
Basically, allow the clickhouseClient
to hold a "sticky session" which can occupy the same connection pool (i.e. respect the same max_open_connections
).
The API could look something like:
const chClient = createClickhouseClient(...)
// All handled in the closure.
await chClient.execStickySession(async (
// maybe a different type that inherits the same ClickhouseClient types but indicates it is sticky?
chClient: ClickhouseClient,
) {
// automatically uses the same session id for the next 2 commands
await chClient.command(...);
await chClient.command(...)
})
// Or explicitly.
const stickySession = await chClient.startStickySession();
try {
...
} finally {
stickySession.close();
}
Describe the alternatives you've considered
We're basically passing 2 different clickhouse clients down the stack now.