[
https://issues.apache.org/jira/browse/CALCITE-903?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14935645#comment-14935645
]
Josh Elser commented on CALCITE-903:
------------------------------------
bq. Note that I fixed CALCITE-843 yesterday, which touched the logic to
synchronize session state.
Ok, thanks for the pointer!
> Enable client to recover from missing server-side state
> -------------------------------------------------------
>
> Key: CALCITE-903
> URL: https://issues.apache.org/jira/browse/CALCITE-903
> Project: Calcite
> Issue Type: Improvement
> Components: avatica
> Reporter: Josh Elser
> Assignee: Josh Elser
> Fix For: 1.5.0-incubating
>
>
> When deploying more than one instance of an avatica-server, we have the
> desire to treat the collection of servers as a single server. Ideally, we
> want to have the avatica-client operate in a manner that doesn't expect a
> server to have specific state For example, the avatica-client should be able
> to know that when a server doesn't have a statement with the ID the client
> thinks it should, the client can create a new statement.
> This is desirable because it allows us to use a generic load-balancer between
> clients and servers without the need for clustering or sticky sessions. The
> downside is that in the face of failure, operations will take longer than
> normal. Even with the performance hit, as long as an avatica-server exists,
> the client can still retrieve the results for some query which is ideal
> (tl;dr it will take longer, but the client still gets the answer).
> Two major areas that need to be addressed presently are:
> 1. Automatic recreation of Statements when they are not cached
> 2. Recreation of ResultSets to resume iteration (for fetch()). This depends
> on "stable results" by the underlying JDBC driver, otherwise external
> synchronization would be required. This is considered a prerequisite.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
