[
https://issues.apache.org/jira/browse/IGNITE-7253?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16363690#comment-16363690
]
Vladimir Ozerov commented on IGNITE-7253:
-----------------------------------------
[~al.psc], I think it is better to split the solution in two parts: hard
streaming mode defined on connection level, and dynamic streaming command. The
key problem with current approach is that it doesn't batch INSERTs on the
client side by default, so any performance gain of streamer will be lost by
high number of network requests. Moreover, current implementation of SET
STREAMING is not aligned with connection string properties. E.g., why I cannot
define streamer buffer size with this command?
I propose to move all dynamic stuff to a separate ticket, and implement current
ticket as follows:
1) Streamer properties are defined in connection string as is
2) Only INSERTs are allowed, all other commands should fail on the server side
3) All commands are batched internally irrespective of whether user uses batch
API or not (because when working with command line tools user typically would
not have a chance to use batching API easily)
4) Local batch size could be controlled with separate property.
5) {{FLUSH}} command is left as is.
A side note - you do not need any complex synchronization logic in
{{SqlClientContext}} as our clients are guaranteed to execute one request at a
time. All CASes could be removed safely, concurrent structures could be
replaced with non-thread-safe counterparts.
> 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
>
>
> 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)
