Uploaded image for project: 'Ignite'
  1. Ignite
  2. IGNITE-18983

Sql. Jdbc. Migrate JDBC handler on new internal API

    XMLWordPrintableJSON

Details

    • Improvement
    • Status: Resolved
    • Major
    • Resolution: Fixed
    • None
    • None
    • jdbc

    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

          Activity

            People

              korlov Konstantin Orlov
              korlov Konstantin Orlov
              Votes:
              0 Vote for this issue
              Watchers:
              2 Start watching this issue

              Dates

                Created:
                Updated:
                Resolved:

                Time Tracking

                  Estimated:
                  Original Estimate - Not Specified
                  Not Specified
                  Remaining:
                  Remaining Estimate - 0h
                  0h
                  Logged:
                  Time Spent - 3h 20m
                  3h 20m