[jira] [Updated] (CALCITE-5009) Transparent JDBC connection re-creation may lead to data loss
[
https://issues.apache.org/jira/browse/CALCITE-5009?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Istvan Toth updated CALCITE-5009:
-
Docs Text:
Avatica will no longer tranparently create a new connection if the proxied
connection object expires from the server side cache.
The transparent reconnection feature can be enabled setting the
"transparent_reconnection" JDBC property to true, but this is only recommended
for connections where losing the connection state, including transactional
state, is not a problem.
However, it is recommended to tune the connection and server side cache
parameters to avoid the cache expiry alltogether.
was:
Avatica will no longer tranparently create a new connection if the proxied
connection object times out from the server side cache.
The transparent reconnection feature can be enabled setting the
"transparent_reconnection" JDBC property to true, but this is only recommended
for connections where losing the connection state, including transactional
state, is not a problem.
However, it is recommended to tune the connection and server side cache
parameters to avoid the cache expiry alltogether.
> Transparent JDBC connection re-creation may lead to data loss
> -
>
> Key: CALCITE-5009
> URL: https://issues.apache.org/jira/browse/CALCITE-5009
> Project: Calcite
> Issue Type: Bug
> Components: avatica
>Reporter: Istvan Toth
>Assignee: Istvan Toth
>Priority: Major
> Time Spent: 40m
> Remaining Estimate: 0h
>
> Currently, if the server-side JDBC connection goes away because it is expored
> from the server-side connection cache we attempt to transparently create a
> new "real" JDBC connection, and continue using that instead of the original
> connection
> [https://github.com/apache/calcite-avatica/blob/fbdcc62745a0e8920db759fb6bdce564d854e407/core/src/main/java/org/apache/calcite/avatica/AvaticaConnection.java#L796]
> This is fine for most read-only connections, but it can break transaction
> semantics, which is captured in the "real" connection object.
> {noformat}
> conn.setAutocommit(false)
> stmt = conn.createStatement()
> execute(insert A)
> //Connection lost and object recreated which now proxies a new "real"
> connection
> execute(insert B)
> conn.commit()
> //We have lost "insert A"{noformat}
> I'm not sure if we synchronize autocommit state of the new connection to the
> lost one or not, but it's bad either way.
>
> We should either completely drop this feature, add some logic that avoids it
> if there is an open transaction and/or only allow it for connections that
> have the readOnly flag set.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (CALCITE-5009) Transparent JDBC connection re-creation may lead to data loss
[
https://issues.apache.org/jira/browse/CALCITE-5009?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Istvan Toth updated CALCITE-5009:
-
Docs Text:
Avatica will no longer tranparently create a new connection if the proxied
connection object times out from the server side cache.
The transparent reconnection feature can be enabled setting the
"transparent_reconnection" JDBC property to true, but this is only recommended
for connections where losing the connection state, including transactional
state, is not a problem.
However, it is recommended to tune the connection and server side cache
parameters to avoid the cache expiry alltogether.
was:
Avatica will no longer tranparently create a new connection if the proxied
connection object times out from the local cache, or becomes invalid for any
other reason.
The transparent reconnection feature can be enabled setting the
"transparent_reconnection" JDBC property to true, but this is only recommended
for connections where losing the connection state, including transactional
state, is not a problem.
> Transparent JDBC connection re-creation may lead to data loss
> -
>
> Key: CALCITE-5009
> URL: https://issues.apache.org/jira/browse/CALCITE-5009
> Project: Calcite
> Issue Type: Bug
> Components: avatica
>Reporter: Istvan Toth
>Assignee: Istvan Toth
>Priority: Major
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> Currently, if the server-side JDBC connection goes away because it is expored
> from the server-side connection cache we attempt to transparently create a
> new "real" JDBC connection, and continue using that instead of the original
> connection
> [https://github.com/apache/calcite-avatica/blob/fbdcc62745a0e8920db759fb6bdce564d854e407/core/src/main/java/org/apache/calcite/avatica/AvaticaConnection.java#L796]
> This is fine for most read-only connections, but it can break transaction
> semantics, which is captured in the "real" connection object.
> {noformat}
> conn.setAutocommit(false)
> stmt = conn.createStatement()
> execute(insert A)
> //Connection lost and object recreated which now proxies a new "real"
> connection
> execute(insert B)
> conn.commit()
> //We have lost "insert A"{noformat}
> I'm not sure if we synchronize autocommit state of the new connection to the
> lost one or not, but it's bad either way.
>
> We should either completely drop this feature, add some logic that avoids it
> if there is an open transaction and/or only allow it for connections that
> have the readOnly flag set.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (CALCITE-5009) Transparent JDBC connection re-creation may lead to data loss
[
https://issues.apache.org/jira/browse/CALCITE-5009?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Istvan Toth updated CALCITE-5009:
-
Description:
Currently, if the server-side JDBC connection goes away because it is expored
from the server-side connection cache we attempt to transparently create a new
"real" JDBC connection, and continue using that instead of the original
connection
[https://github.com/apache/calcite-avatica/blob/fbdcc62745a0e8920db759fb6bdce564d854e407/core/src/main/java/org/apache/calcite/avatica/AvaticaConnection.java#L796]
This is fine for most read-only connections, but it can break transaction
semantics, which is captured in the "real" connection object.
{noformat}
conn.setAutocommit(false)
stmt = conn.createStatement()
execute(insert A)
//Connection lost and object recreated which now proxies a new "real" connection
execute(insert B)
conn.commit()
//We have lost "insert A"{noformat}
I'm not sure if we synchronize autocommit state of the new connection to the
lost one or not, but it's bad either way.
We should either completely drop this feature, add some logic that avoids it if
there is an open transaction and/or only allow it for connections that have the
readOnly flag set.
was:
Currently, if the server-side JDBC connection goes away for any reason
* Avatica server connection cache expiry
* -LB/HA Failover-
* -Some problem with the "real" connection-
we attempt to create a new "real" JDBC connection, and continue using that
instead of the original connection
[https://github.com/apache/calcite-avatica/blob/fbdcc62745a0e8920db759fb6bdce564d854e407/core/src/main/java/org/apache/calcite/avatica/AvaticaConnection.java#L796]
This is fine for most read-only connections, but it can break transaction
semantics, which is captured in the "real" connection object.
{noformat}
conn.setAutocommit(false)
stmt = conn.createStatement()
execute(insert A)
//Connection lost and object recreated which now proxies a new "real" connection
execute(insert B)
conn.commit()
//We have lost "insert A"{noformat}
I'm not sure if we synchronize autocommit state of the new connection to the
lost one or not, but it's bad either way.
We should either completely drop this feature, add some logic that avoids it if
there is an open transaction and/or only allow it for connections that have the
readOnly flag set.
> Transparent JDBC connection re-creation may lead to data loss
> -
>
> Key: CALCITE-5009
> URL: https://issues.apache.org/jira/browse/CALCITE-5009
> Project: Calcite
> Issue Type: Bug
> Components: avatica
>Reporter: Istvan Toth
>Assignee: Istvan Toth
>Priority: Major
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> Currently, if the server-side JDBC connection goes away because it is expored
> from the server-side connection cache we attempt to transparently create a
> new "real" JDBC connection, and continue using that instead of the original
> connection
> [https://github.com/apache/calcite-avatica/blob/fbdcc62745a0e8920db759fb6bdce564d854e407/core/src/main/java/org/apache/calcite/avatica/AvaticaConnection.java#L796]
> This is fine for most read-only connections, but it can break transaction
> semantics, which is captured in the "real" connection object.
> {noformat}
> conn.setAutocommit(false)
> stmt = conn.createStatement()
> execute(insert A)
> //Connection lost and object recreated which now proxies a new "real"
> connection
> execute(insert B)
> conn.commit()
> //We have lost "insert A"{noformat}
> I'm not sure if we synchronize autocommit state of the new connection to the
> lost one or not, but it's bad either way.
>
> We should either completely drop this feature, add some logic that avoids it
> if there is an open transaction and/or only allow it for connections that
> have the readOnly flag set.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (CALCITE-5009) Transparent JDBC connection re-creation may lead to data loss
[
https://issues.apache.org/jira/browse/CALCITE-5009?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Istvan Toth updated CALCITE-5009:
-
Description:
Currently, if the server-side JDBC connection goes away for any reason
* Avatica server connection cache expiry
* -LB/HA Failover-
* -Some problem with the "real" connection-
we attempt to create a new "real" JDBC connection, and continue using that
instead of the original connection
[https://github.com/apache/calcite-avatica/blob/fbdcc62745a0e8920db759fb6bdce564d854e407/core/src/main/java/org/apache/calcite/avatica/AvaticaConnection.java#L796]
This is fine for most read-only connections, but it can break transaction
semantics, which is captured in the "real" connection object.
{noformat}
conn.setAutocommit(false)
stmt = conn.createStatement()
execute(insert A)
//Connection lost and object recreated which now proxies a new "real" connection
execute(insert B)
conn.commit()
//We have lost "insert A"{noformat}
I'm not sure if we synchronize autocommit state of the new connection to the
lost one or not, but it's bad either way.
We should either completely drop this feature, add some logic that avoids it if
there is an open transaction and/or only allow it for connections that have the
readOnly flag set.
was:
Currently, if the server-side JDBC connection goes away for any reason
* Avatica connection cache expiry
* LB/HA Failover
* Some problem with the "real" connection
we attempt to create a new "real" JDBC connection, and continue using that
instead of the original connection
[https://github.com/apache/calcite-avatica/blob/fbdcc62745a0e8920db759fb6bdce564d854e407/core/src/main/java/org/apache/calcite/avatica/AvaticaConnection.java#L796]
This is fine for most read-only connections, but it can break transaction
semantics, which is captured in the "real" connection object.
{noformat}
conn.setAutocommit(false)
stmt = conn.createStatement()
execute(insert A)
//Connection lost and object recreated which now proxies a new "real" connection
execute(insert B)
conn.commit()
//We have lost "insert A"{noformat}
I'm not sure if we synchronize autocommit state of the new connection to the
lost one or not, but it's bad either way.
We should either completely drop this feature, add some logic that avoids it if
there is an open transaction and/or only allow it for connections that have the
readOnly flag set.
> Transparent JDBC connection re-creation may lead to data loss
> -
>
> Key: CALCITE-5009
> URL: https://issues.apache.org/jira/browse/CALCITE-5009
> Project: Calcite
> Issue Type: Bug
> Components: avatica
>Reporter: Istvan Toth
>Assignee: Istvan Toth
>Priority: Major
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> Currently, if the server-side JDBC connection goes away for any reason
> * Avatica server connection cache expiry
> * -LB/HA Failover-
> * -Some problem with the "real" connection-
> we attempt to create a new "real" JDBC connection, and continue using that
> instead of the original connection
> [https://github.com/apache/calcite-avatica/blob/fbdcc62745a0e8920db759fb6bdce564d854e407/core/src/main/java/org/apache/calcite/avatica/AvaticaConnection.java#L796]
> This is fine for most read-only connections, but it can break transaction
> semantics, which is captured in the "real" connection object.
> {noformat}
> conn.setAutocommit(false)
> stmt = conn.createStatement()
> execute(insert A)
> //Connection lost and object recreated which now proxies a new "real"
> connection
> execute(insert B)
> conn.commit()
> //We have lost "insert A"{noformat}
> I'm not sure if we synchronize autocommit state of the new connection to the
> lost one or not, but it's bad either way.
>
> We should either completely drop this feature, add some logic that avoids it
> if there is an open transaction and/or only allow it for connections that
> have the readOnly flag set.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (CALCITE-5009) Transparent JDBC connection re-creation may lead to data loss
[
https://issues.apache.org/jira/browse/CALCITE-5009?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Istvan Toth updated CALCITE-5009:
-
Docs Text:
Avatica will no longer tranparently create a new connection if the proxied
connection object times out from the local cache, or becomes invalid for any
other reason.
The transparent reconnection feature can be enabled setting the
"transparent_reconnection" JDBC property to true, but this is only recommended
for connections where losing the connection state, including transactional
state, is not a problem.
> Transparent JDBC connection re-creation may lead to data loss
> -
>
> Key: CALCITE-5009
> URL: https://issues.apache.org/jira/browse/CALCITE-5009
> Project: Calcite
> Issue Type: Bug
> Components: avatica
>Reporter: Istvan Toth
>Assignee: Istvan Toth
>Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Currently, if the server-side JDBC connection goes away for any reason
> * Avatica connection cache expiry
> * LB/HA Failover
> * Some problem with the "real" connection
> we attempt to create a new "real" JDBC connection, and continue using that
> instead of the original connection
> [https://github.com/apache/calcite-avatica/blob/fbdcc62745a0e8920db759fb6bdce564d854e407/core/src/main/java/org/apache/calcite/avatica/AvaticaConnection.java#L796]
> This is fine for most read-only connections, but it can break transaction
> semantics, which is captured in the "real" connection object.
> {noformat}
> conn.setAutocommit(false)
> stmt = conn.createStatement()
> execute(insert A)
> //Connection lost and object recreated which now proxies a new "real"
> connection
> execute(insert B)
> conn.commit()
> //We have lost "insert A"{noformat}
> I'm not sure if we synchronize autocommit state of the new connection to the
> lost one or not, but it's bad either way.
>
> We should either completely drop this feature, add some logic that avoids it
> if there is an open transaction and/or only allow it for connections that
> have the readOnly flag set.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (CALCITE-5009) Transparent JDBC connection re-creation may lead to data loss
[
https://issues.apache.org/jira/browse/CALCITE-5009?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Julian Hyde updated CALCITE-5009:
-
Summary: Transparent JDBC connection re-creation may lead to data loss
(was: Make sure transaparent jdbc connection re-creation does not lead to data
loss)
> Transparent JDBC connection re-creation may lead to data loss
> -
>
> Key: CALCITE-5009
> URL: https://issues.apache.org/jira/browse/CALCITE-5009
> Project: Calcite
> Issue Type: Bug
> Components: avatica
>Reporter: Istvan Toth
>Priority: Major
>
> Currently, if the server-side JDBC connection goes away for any reason
> * Avatica connection cache expiry
> * LB/HA Failover
> * Some problem with the "real" connection
> we attempt to create a new "real" JDBC connection, and continue using that
> instead of the original connection
> [https://github.com/apache/calcite-avatica/blob/fbdcc62745a0e8920db759fb6bdce564d854e407/core/src/main/java/org/apache/calcite/avatica/AvaticaConnection.java#L796]
> This is fine for most read-only connections, but it can break transaction
> semantics, which is captured in the "real" connection object.
> {noformat}
> conn.setAutocommit(false)
> stmt = conn.createStatement()
> execute(insert A)
> //Connection lost and object recreated which now proxies a new "real"
> connection
> execute(insert B)
> conn.commit()
> //We have lost "insert A"{noformat}
> I'm not sure if we synchronize autocommit state of the new connection to the
> lost one or not, but it's bad either way.
>
> We should either completely drop this feature, add some logic that avoids it
> if there is an open transaction and/or only allow it for connections that
> have the readOnly flag set.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
