Description
Problem
Currently, JDBC implementation uses old entrypoint to QueryProcessor: QueryProcessor#queryAsync(...). It lacks proper integration with transaction, as well as session management.
As a first step, let's migrate only subset of execute* methods: executeQuery and executeUpdate. Execution of the arbitrary script (Statement#execute), as well as execution of batched methods (*Statement#executeBatch) will be addressed in the follow up tickets.
Implementation notes
This task consists of two parts.
The first one is the session management. JdbcConnection should create new session with the very first request and reuse it while it is valid. The session may unexpectedly be invalidated for number of reasons, thus some recovery procedure is needed. An approximate algorithm might look like this:
Session initialization
1) with the very first request, client sends sessions params alongside with the request
2) server issues client connection id (ccId) and save these params alonside with ccId in connection context
3) server creates new session with provided params and save session id in the connection context
4) server executes request within created session
5) server respond to the client with response and ccId from the p.2
6) client saves ccId
7) from this point, all following request must include ccId
Session recovery
1) server receives the request with ccId
2) server retrieves the context by ccId
3) server retrieves the sessionId from context
4) server tries to execute request within the session
5) if session is invalidated, server tries to recreate the session and retries the operation (pp.3-5 from previous algorithm)
The second part is just migration from queryAsync to querySingleAsync. Looks pretty straitforward to me..
Attachments
Issue Links
- blocks
-
IGNITE-18984 Sql. Jdbc. Migrate batched methods on new internal API
- Resolved
- links to