[
https://issues.apache.org/jira/browse/IGNITE-18983?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yury Gerzhedovich updated IGNITE-18983:
---------------------------------------
Epic Link: IGNITE-14858
> 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
> Priority: Major
> Labels: ignite-3
>
> 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)
