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

Vladimir Ozerov edited comment on IGNITE-7253 at 3/2/18 12:56 PM:
------------------------------------------------------------------

[~al.psc], my comments:
1) ConnectionPropertiesImpl.LongProperty - appears to be a dead code
2) org.apache.ignite.internal.jdbc.thin.JdbcThinConnection#setStream - dead code
3) JdbcThinStatement.isEligibleForNativeParsing - executed twice every time. 
Why?
4) GridQueryProcessor.cliCtxs - why do we need to track these objects? AFAIK 
data streamers are already closed by DataStreamerProcessor during node stop
5) JdbcThinConnection - why do we need {{synchronized}} on some methods? 
Connection is single-threaded object already.
6) JdbcThinConnection.drainBatchToStreamIfNeeded - looks like it would return 
incorrect update count when executed on half-formed batch; IMO it is better to 
throw an exception if there is something prebatched.
7) Looks like it is allowed to execute DDL statements in streaming mode at the 
moment ({{streamBatchedUpdateQuery}} -> 
{{tryQueryDistributedSqlFieldsNative}}), which is wrong. Instead of adding a 
command to batch, I would set a special flag in it to close the streaming. This 
way you would not have to parse {{STREAMING OFF}} on the server.


was (Author: vozerov):
[~al.psc], my comments:
1) ConnectionPropertiesImpl.LongProperty - appears to be a dead code
2) org.apache.ignite.internal.jdbc.thin.JdbcThinConnection#setStream - dead code
3) JdbcThinStatement.isEligibleForNativeParsing - executed twice every time. 
Why?
4) GridQueryProcessor.cliCtxs - why do we need to track these objects? AFAIK 
data streamers are already closed by DataStreamerProcessor during node stop
5) JdbcThinConnection - why do we need {{synchronized}} on some methods? 
Connection is single-threaded object already.
6) JdbcThinConnection.drainBatchToStreamIfNeeded - looks like it would return 
incorrect update count when executed on half-formed batch; IMO it is better to 
throw an exception if there is something prebatched.

> JDBC thin driver: introduce streaming mode
> ------------------------------------------
>
>                 Key: IGNITE-7253
>                 URL: https://issues.apache.org/jira/browse/IGNITE-7253
>             Project: Ignite
>          Issue Type: Task
>          Components: jdbc, sql
>            Reporter: Vladimir Ozerov
>            Assignee: Alexander Paschenko
>            Priority: Major
>             Fix For: 2.5
>
>         Attachments: IGNITE_7253.patch
>
>
> Should be done after IGNITE-6022. We should allow optional streaming mode for 
> JDBC driver. In this mode only INSERTs without SELECT should be possible. All 
> other DML operations should throw an exception. 
> Design considerations:
> 1) Add command {{SET STREAMING=1|ON|0|OFF}} which will enable or disable 
> streaming for connection.
> 2) Add command {{STREAMER FLUSH}} which will force data flush.
> 3) Only INSERT without SELECT works, all other DML statements should throw an 
> exception
> 4) It should be possible to stream into several tables simultaneously (i.e. 
> several streamers could be opened)
> 5) Any DDL statement should force flush of all currently opened streamers.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

Reply via email to