Skip to content

introduce "sticky session" concept for handling temporary tables #381

Open
@otan

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.

Metadata

Assignees

No one assigned

    Labels

    enhancementNew feature or request

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions