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 <[email protected]> wrote: > > What are the user-facing benefits of this?
