Hi all, Could IEP-129 provide the propagation layer by carrying a session token with every operation, including reconnects and remote query fragments?
If so, could the proposal focus on the missing parts: trusted session creation, lifecycle, fencing, temporary-data storage, and cleanup? Do we need a general cluster-wide session abstraction, or would a smaller SQL-specific extension of the existing context mechanism be sufficient? More generally, could the proposed session concept and the existing SessionContext API be combined into a single coherent model? Sincerely, Dmitriy Pavlov пт, 28 авг. 2026 г. в 00:27, Aleksandr Chesnokov <[email protected]>: > Hi Kirill, > > In your first email, question 7 asks where session state should live. For > temporary tables I think there are two questions here, and the second one > is more difficult. > > The registry is small part: session id, owner, auth context, timeout. It > can live on one node or it can be replicated. Both options work. > > The rows are the difficult part. They can be large and SQL runs on many > nodes. If we keep the rows on the session node, query fragments on other > nodes cannot read them without extra routing. If we distribute the rows, > they become like cache data: partitioning, backups, rebalance, a session > check on every read and write, and cleanup on all nodes when the session > ends. This also includes the case when the client just disappears. > > Which option do you have in mind for the rows? In particular: > > - Should query fragments on other nodes read the temporary-table rows > directly? > > - Should temporary-table data survive failure of the session-owning node, > or is losing the session and its temporary data acceptable in that case? > > I ask because I started IGNITE-28614 (SessionContext for the thin client) > earlier this year and then stopped, because there was no use case for it. > Temporary tables can be such a use case, but a stateful SQL session needs > more than context propagation. > > Regards, > Aleksandr
