[DISCUSSION] Introducing a session concept in Apache Ignite 2

[ткаленко кирилл <tk...@yandex.ru>]

Hi Igniters,

While looking at context propagation across SQL and key-value operations in
Apache Ignite 2, I noticed that Ignite 2 does not seem to have a first-class, session abstraction.

There are connection-specific contexts in the JDBC, ODBC, and thin client layers. 
There is also SessionContext for application attributes. However, as far as I can see, 
there is no stable session identity and lifecycle shared by multiple SQL and key-value operations.

Before considering an implementation, I would like to understand:

1. Was the absence of a unified session concept in Apache Ignite 2 an intentional architectural decision?

2. Are there any known objections to introducing a session abstraction shared by the SQL and key-value APIs?

3. What should define a session boundary:
   - a physical client connection;
   - a logical client connection;
   - an explicit session handle;
   - or something else?

4. How should embedded APIs, which do not necessarily have a client connection, participate in a session?

5. What should be the relationship between a session and a transaction?
   A session may contain multiple transactions, but are there cases where a transaction can be used without a session?

6. What should happen on reconnect, connection loss, coordinator node failure, or client failover? 
  Should a new connection always create a new session?

7. Should session state exist only on the connection/coordinator node, or should it be distributed or replicated?

8. How should the session identity be propagated to nodes executing remote SQL fragments and key-value operations?

9. Are there compatibility, security, resource cleanup, performance, or protocol concerns specific to Apache Ignite 2 that should be considered?

A possible initial implementation could provide:

- a globally unique session ID;
- a lifecycle tied to a logical client connection;
- an explicit session context for embedded APIs;
- propagation through SQL query and key-value operation contexts;
- a registry for session-scoped state and resources;
- cleanup on connection close, disconnect, or coordinator node failure;
- no session recovery after reconnect in the initial version.

Such an abstraction could provide a common foundation for operation attribution, 
resource accounting, observability, session-specific settings, application context, 
and other state shared across SQL and key-value operations.

Would this abstraction fit the Apache Ignite 2 architecture? Are there historical reasons or important edge cases that should be taken into account?

Re: [DISCUSSION] Introducing a session concept in Apache Ignite 2

[Vladislav Pyatkov <vl...@gmail.com>]

Hi all,

I'd like to add my two cents to the discussion.


   1. As I understand it, IEP-129 mainly provides propagated application
   context. Some attributes can be changed during the lifetime of a JDBC
   connection via setClientInfo, but there does not seem to be a general
   mutable session state. Is that sufficient if we want to model an SQL
   session? The SQL standard, as far as I understand, assumes that some
   session state and characteristics may change during the lifetime of a
   session.
   2. Pavel, regarding your question about the user-facing benefits,
   temporary tables seem to be a good example. SQL temporary tables are
   normally scoped to a session. How would session-scoped temporary tables be
   implemented with the stateless IEP-129 approach? It seems that this use
   case requires both a stable session identity and some server-side state
   tied to its lifecycle.
   3. I also have a question about session identity and security. IEP-129
   allows an application to propagate something like SESSION_ID as an ordinary
   application attribute. But if we start using this ID to access
   session-scoped server-side state, who is responsible for generating and
   validating it? A client-provided ID seems insufficient from a security
   perspective: uniqueness alone would not prevent one client from presenting
   another session's ID. Would a first-class session therefore need a
   server-controlled identity bound to the authenticated user?


On Thu, Aug 20, 2026 at 7:24 PM Maksim Timonin <ti...@apache.org>
wrote:

> Hi Kirill,
>
> Part of what you describe already exists in Ignite 2 — see IEP-129
> "Application attributes and SessionContext API" [1]. It lets an application
> attach a string attribute map at the API entry point —
> Ignite#withApplicationAttributes() for embedded mode,
> Connection.setClientInfo() for JDBC — and read it on server nodes inside
> CacheInterceptor and Calcite SQL UDFs via SessionContext injected with
> @SessionContextProviderResource. The IEP also proposed
> IgniteClient#withApplicationAttributes() for the thin client and injection
> into Services/Compute, but those parts haven't been implemented yet —
> contributions welcome.
>
> The key design decision in IEP-129, which answers several of your
> questions, is that there is deliberately no server-side session state.
> Attributes are propagated by value with each operation: JDBC re-sends them
> with every request, and key-value operations carry them on the cache
> messages themselves (atomic update and tx-prepare wrappers), including
> transactional operations where they're attached to the tx. This means
> reconnect, client failover, and coordinator failure need no special
> handling — there is nothing to recover or clean up — and remote SQL
> fragments / primary-node KV operations see the context without any registry
> lookup.
>
> So to your questions: the absence of a stateful session was, at least in
> IEP-129, an intentional trade-off, partly because Ignite 2 has no single
> physical connection to bind a session to (the thin client keeps multiple
> connections open for partition awareness, JDBC reconnects transparently).
> The "explicit handle" model (withApplicationAttributes) is the existing
> precedent for embedded APIs.
>
> What IEP-129 does not give you is a session identity, lifecycle, and a
> registry for session-scoped resources — that would be genuinely new. If
> your use cases (resource accounting, session-scoped settings) require
> server-side state keyed by a session ID, I'd suggest framing the proposal
> as an extension of the SessionContext API: the propagation mechanism can
> carry the session ID as an attribute already; the new work is the registry,
> its cleanup on client disconnect/failure, and the security/compat story.
> Before that, it would help to state which concrete use case can't be served
> by the stateless attribute model — that was the bar IEP-129 set.
>
> If you have any questions - you're welcome, can discuss on short call if
> needed.
>
> TL;DR:
>
> *Q1 *(intentional?) - Ignite 2 has no single physical connection to bind a
> session to, withApplicationAttrubutes is an attempt to introduce it.
> *Q2 *(existing abstractions) - yes, see IEP-129 [1].
> *Q3* (session boundary) — Ignite 2 has no good "physical connection"
> boundary anyway: the thin client opens multiple connections for partition
> awareness, and JDBC can reconnect transparently. The IEP's answer was "the
> API entry point object":  whoever holds the decorated Ignite instance /
> JDBC connection is the scope.
> *Q4* (embedded APIs) — withApplicationAttributes is effectively an explicit
> context handle with no connection involved. A session handle for embedded
> mode would naturally follow the same shape.
> *Q5* (transactions) — attributes are attached to the transaction object
> (IgniteInternalTx#applicationAttributes) and win over the per-call context,
> so "context outlives/spans a tx" already works.
> *Q6* (reconnect/failover) — the per-request re-send in JDBC exists
> precisely so retries and failover need no session recovery. Any stateful
> session would have to solve what IEP-129 avoided.
> *Q8* (propagation) — the mechanism exists and is reusable: a session ID is
> just one more propagated attribute. What does not exist is anything keyed
> by that ID on the server.
> *Q7* (distributed state?) — IEP-129's design is evidence of an intentional
> choice: no session identity, no registry, no server-side state. Attributes
> travel with each message, so there is nothing to replicate, clean up, or
> recover. That sidesteps the hardest questions on the list (coordinator
> failure, cleanup, reconnect) at the cost of not having an identity at all.
> *Q9* (risks) — the IEP flags: no security validation of attribute values,
> string-only keys/values to avoid serialization issues, "keep them few and
> small", and protocol compatibility handled via feature flags
> (JdbcThinFeature.CLIENT_INFO, ClientBitmaskFeature).
>
> [1]
>
> https://cwiki.apache.org/confluence/spaces/IGNITE/pages/321718789/IEP-129+Application+attributes+and+SessionContext+API
>
>
> On Thu, Aug 20, 2026 at 4:59 PM Pavel Tupitsyn <pt...@apache.org>
> wrote:
> >
> > What are the user-facing benefits of this?
>


-- 
Vladislav Pyatkov

Re: [DISCUSSION] Introducing a session concept in Apache Ignite 2

[Maksim Timonin <ti...@apache.org>]

Hi Kirill,

Part of what you describe already exists in Ignite 2 — see IEP-129
"Application attributes and SessionContext API" [1]. It lets an application
attach a string attribute map at the API entry point —
Ignite#withApplicationAttributes() for embedded mode,
Connection.setClientInfo() for JDBC — and read it on server nodes inside
CacheInterceptor and Calcite SQL UDFs via SessionContext injected with
@SessionContextProviderResource. The IEP also proposed
IgniteClient#withApplicationAttributes() for the thin client and injection
into Services/Compute, but those parts haven't been implemented yet —
contributions welcome.

The key design decision in IEP-129, which answers several of your
questions, is that there is deliberately no server-side session state.
Attributes are propagated by value with each operation: JDBC re-sends them
with every request, and key-value operations carry them on the cache
messages themselves (atomic update and tx-prepare wrappers), including
transactional operations where they're attached to the tx. This means
reconnect, client failover, and coordinator failure need no special
handling — there is nothing to recover or clean up — and remote SQL
fragments / primary-node KV operations see the context without any registry
lookup.

So to your questions: the absence of a stateful session was, at least in
IEP-129, an intentional trade-off, partly because Ignite 2 has no single
physical connection to bind a session to (the thin client keeps multiple
connections open for partition awareness, JDBC reconnects transparently).
The "explicit handle" model (withApplicationAttributes) is the existing
precedent for embedded APIs.

What IEP-129 does not give you is a session identity, lifecycle, and a
registry for session-scoped resources — that would be genuinely new. If
your use cases (resource accounting, session-scoped settings) require
server-side state keyed by a session ID, I'd suggest framing the proposal
as an extension of the SessionContext API: the propagation mechanism can
carry the session ID as an attribute already; the new work is the registry,
its cleanup on client disconnect/failure, and the security/compat story.
Before that, it would help to state which concrete use case can't be served
by the stateless attribute model — that was the bar IEP-129 set.

If you have any questions - you're welcome, can discuss on short call if
needed.

TL;DR:

*Q1 *(intentional?) - Ignite 2 has no single physical connection to bind a
session to, withApplicationAttrubutes is an attempt to introduce it.
*Q2 *(existing abstractions) - yes, see IEP-129 [1].
*Q3* (session boundary) — Ignite 2 has no good "physical connection"
boundary anyway: the thin client opens multiple connections for partition
awareness, and JDBC can reconnect transparently. The IEP's answer was "the
API entry point object":  whoever holds the decorated Ignite instance /
JDBC connection is the scope.
*Q4* (embedded APIs) — withApplicationAttributes is effectively an explicit
context handle with no connection involved. A session handle for embedded
mode would naturally follow the same shape.
*Q5* (transactions) — attributes are attached to the transaction object
(IgniteInternalTx#applicationAttributes) and win over the per-call context,
so "context outlives/spans a tx" already works.
*Q6* (reconnect/failover) — the per-request re-send in JDBC exists
precisely so retries and failover need no session recovery. Any stateful
session would have to solve what IEP-129 avoided.
*Q8* (propagation) — the mechanism exists and is reusable: a session ID is
just one more propagated attribute. What does not exist is anything keyed
by that ID on the server.
*Q7* (distributed state?) — IEP-129's design is evidence of an intentional
choice: no session identity, no registry, no server-side state. Attributes
travel with each message, so there is nothing to replicate, clean up, or
recover. That sidesteps the hardest questions on the list (coordinator
failure, cleanup, reconnect) at the cost of not having an identity at all.
*Q9* (risks) — the IEP flags: no security validation of attribute values,
string-only keys/values to avoid serialization issues, "keep them few and
small", and protocol compatibility handled via feature flags
(JdbcThinFeature.CLIENT_INFO, ClientBitmaskFeature).

[1]
https://cwiki.apache.org/confluence/spaces/IGNITE/pages/321718789/IEP-129+Application+attributes+and+SessionContext+API


On Thu, Aug 20, 2026 at 4:59 PM Pavel Tupitsyn <pt...@apache.org> wrote:
>
> What are the user-facing benefits of this?

Re: [DISCUSSION] Introducing a session concept in Apache Ignite 2

[Pavel Tupitsyn <pt...@apache.org>]

What are the user-facing benefits of this?