[jira] [Commented] (IGNITE-18983) Sql. Jdbc. Migrate JDBC handler on new internal API

["Yury Gerzhedovich (Jira)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/IGNITE-18983?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17704645#comment-17704645 ] 

Yury Gerzhedovich commented on IGNITE-18983:
--------------------------------------------

[~korlov] , LGTM! Thanks for your contribution!

> Sql. Jdbc. Migrate JDBC handler on new internal API
> ---------------------------------------------------
>
>                 Key: IGNITE-18983
>                 URL: https://issues.apache.org/jira/browse/IGNITE-18983
>             Project: Ignite
>          Issue Type: Improvement
>          Components: jdbc
>            Reporter: Konstantin Orlov
>            Assignee: Konstantin Orlov
>            Priority: Major
>              Labels: ignite-3
>          Time Spent: 3h 10m
>  Remaining Estimate: 0h
>
> h3. 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.
> h3. 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:
> h4. 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
> h4. 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..



--
This message was sent by Atlassian Jira
(v8.20.10#820010)