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?
