[
https://issues.apache.org/jira/browse/CALCITE-767?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15023902#comment-15023902
]
James Taylor commented on CALCITE-767:
--------------------------------------
One complication of implementing this in Avatica brought up by [~elserj] is how
to implement commit while preserving our "stateless client" approach.
Specifically, say you're access a query server behind some "dumb" load
balancer. You do some stuff, but before you call commit(), the server dies. How
does the client handle this? When autocommit=off, do we buffer this in memory
on the client and automatically replay the calls since the last commit()?
A similar issue might be if the same client connection ends up getting a
different query server node due to the load balancer. How is the uncommitted
state maintained across different query server nodes?
For transactional tables, one potential solution is that when a statement
causes a transaction to start, we return back the transaction metadata as part
of the response. The metadata would vary based on the implementation, but for
Phoenix the state that would need to be captured is based on Tephra's
Transaction object[1]. The query server would need to ensure that the data for
each statement was flushed to the cluster prior to returning (see PHOENIX-2411
for more detail). With transactions, the data can essentially be written to
HBase, but not yet considered committed. Ideally, a transaction implementation
could give back a simple transaction ID which would capture this metadata
For non transactional tables, other than carrying around the uncommitted data
on the client (which probably isn't such a scalable solution for a true thin
driver), I can't think of another better solution.
[1]
https://github.com/caskdata/tephra/blob/develop/tephra-api/src/main/java/co/cask/tephra/Transaction.java.
> Commit functionality not exposed by the RPC server
> --------------------------------------------------
>
> Key: CALCITE-767
> URL: https://issues.apache.org/jira/browse/CALCITE-767
> Project: Calcite
> Issue Type: Improvement
> Components: avatica
> Reporter: Lukas Lalinsky
>
> It seems that the commit/rollback functionality is not exposed by the RPC
> server, which means that it's only usable in autocommit mode. Avatica itself
> doesn't have a concept of commit in the RPC and the remote JDBC connection
> raises an exception when calling commit() on it, but Phoenix's native JDBC
> connection does implement commit(), so the RPC needs to be extended to allow
> calling that remotely.
> The easiest way to test this, "!autocommit off" and then "!commit" fails in
> "sqline-thin.py", but works in "sqline.py".
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
