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
