You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@calcite.apache.org by "Josh Elser (JIRA)" <ji...@apache.org> on 2015/12/08 17:36:10 UTC
[jira] [Commented] (CALCITE-767) Commit functionality not exposed
by the RPC server
[ https://issues.apache.org/jira/browse/CALCITE-767?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15047044#comment-15047044 ]
Josh Elser commented on CALCITE-767:
------------------------------------
I've been racking my brains trying to come up with a better way around this for non-transactional tables (as James outlined above), and I'm just not coming up with anything better. This might be an area where operating stateless-ly just isn't feasible for a first-pass implementation.
I think my approach might be to make the assumption that communications are going to a single instance for now, and come up with more robust strategies later.
> 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)