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