FlightSqlServiceClient stores the bearer token it receives on the Handshake response and uses it on all subsequent requests. The Flight protocol does not clearly specify whether the bearer token has to be sent on DoGet calls as well (along with the ticket). Because of this, several Flight SQL server implementors decided to expect the bearer token on DoGet requests.
However, if the DoGet call needs to go to a different endpoint, or when the client decides to parallelise the streams and have the DoGet calls performed by different threads (or even nodes), the new client instances cannot access the bearer token simply because the field is private and only writable (set and clear).
Adding a "getter" would solve this problem and allow the client app to propagate the token to distributed DoGet calls.
FlightSqlServiceClient
stores the bearer token it receives on the Handshake response and uses it on all subsequent requests. The Flight protocol does not clearly specify whether the bearer token has to be sent on DoGet calls as well (along with the ticket). Because of this, several Flight SQL server implementors decided to expect the bearer token on DoGet requests. However, if theDoGet
call needs to go to a different endpoint, or when the client decides to parallelise the streams and have theDoGet
calls performed by different threads (or even nodes), the new client instances cannot access the bearer token simply because the field is private and only writable (set and clear).Adding a "getter" would solve this problem and allow the client app to propagate the token to distributed DoGet calls.