[
https://issues.apache.org/jira/browse/IGNITE-5439?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16711231#comment-16711231
]
Vladimir Ozerov commented on IGNITE-5439:
-----------------------------------------
[~alapin], [~tledkov-gridgain], my comments (haven't seen JDBC thin part for
now):
# ClientMessageParser.decodeCommandType - why do we create
{{BinaryRawReaderEx}} here? {{inStream.readShort()}} should be enough, isn't it?
# SqlStateCode - it seems that you picked code from ODBC standard. JDBC version
should be used (most likely it is either S1000 or 70100) - see
{{ER_QUERY_INTERRUPTED}} in [1]
# {{IgniteQueryErrorCode.QUERY_CANCELED = 57014}} - why did we pick this value?
# {{ClientListenerNioRequestPriorityFilter}} - I am not satisfied with code
duplication here. Essentially, filter should do only one thing - either
delegate to the next asynchronous filter or not. No execution should happen
here. May be it will be enough to add "sync" check to async filter
{{onMessageReceived}} method in {{ClientListenerProcessor.makeFilters}} and
then either delegate to super (i.e. execute asynchronously), or execute right
away (synchronously).
# {{JdbcRequestHandler.CONN_CLEANUP_PERIOD}} - could you please explain why we
need it? I hardly can image how query cancel feature may require so many
additional collections. Looks like a design flaw.
[1]
https://dev.mysql.com/doc/connector-j/5.1/en/connector-j-reference-error-sqlstates.html
> JDBC thin: support query cancel
> -------------------------------
>
> Key: IGNITE-5439
> URL: https://issues.apache.org/jira/browse/IGNITE-5439
> Project: Ignite
> Issue Type: Task
> Components: jdbc
> Affects Versions: 2.0
> Reporter: Taras Ledkov
> Assignee: Alexander Lapin
> Priority: Major
> Fix For: 2.8
>
>
> The JDBC {{Statement.cancel}} method must be supported.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
