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

Julian Hyde commented on CALCITE-903:
-------------------------------------

Sounds good. Note that I fixed CALCITE-843 yesterday, which touched the logic 
to synchronize session state.

> 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)

Reply via email to