[
https://issues.apache.org/jira/browse/IGNITE-18983?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Konstantin Orlov updated IGNITE-18983:
--------------------------------------
Description:
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.
was:
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
JdbcConnection should created session with the very first request, reuse the
same session while it is valid, and recreated the session on the next request
if it was invalidated.
> 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)
