Do you need this beyond FlightSQL? Since any user/client interface to a server is going to require some custom development anyway (just like the server requires custom development), if there is a need to close resources, it seems like this could be implemented by an action that is specific to the particular client/server implementation (such as FlightSQL).
On Fri, Oct 30, 2020 at 4:43 PM Kyle Porter <ky...@bitquilltech.com> wrote: > > Hi, > > Carrying on from this thread: > https://mail-archives.apache.org/mod_mbox/arrow-dev/202010.mbox/%3CCAJPUwMA25jprszWEsrL2zr0xz%3DgsqdB%3D_4jP06eG8S8b5--mdg%40mail.gmail.com%3E > (apologies, as I was not a member of the list at the time of this thread > starting and am unsure if it's possible to reply directly after the fact), > I think there are a few options we can use to manage session lifetimes. > > As Wes suggested, we could add some RPC calls, but given that FlightServer > (as I understand it) is meant to be stateless by default it seems odd that > we would elevate these to top-level RPC calls. > > An alternative would be to build on > https://issues.apache.org/jira/browse/ARROW-10427 and, when using session > headers, to allow the specification of an optional close handler for the > FlightServer. This would then add a "close" Action to the server which > would invoke the closeHandler for release of the session resources. > > We would then maintain a clear distinction between stateless FlightServers > and those that opt into session headers where there may be state, and the > ability to close would be restricted to when state is implied. > > Feedback on the idea would be appreciated. > > *Kyle Porter*
