Hey Radim, thanks for bringing this to the list.
In general, I'm supportive of the second option you shared ("Exposing neutral
methods") but want to make sure I understand how CRaC would work in practice.
Could you clarify this part:
> Naturally it is possible to close the session object completely and create a
> new one, but the ideal solution would require no application changes beyond
> dependency upgrade.
CRaC doesn't support checkpointing with open sockets, and the Cassandra client
protocol requires a few roundtrips after connection establishment before a
session can be used[1]. Would it be possible to have a separate CqlSession
implementation that includes CRaC's checkpoint and restore hooks[2] to close
and open the session at the appropriate times? This CRaC implementation could
live as a third-party module initially as it is proven out.
[1]:
https://github.com/apache/cassandra/blob/trunk/doc/native_protocol_v5.spec#L176
[2]: https://docs.azul.com/core/crac/crac-guidelines#implementing-crac-resource
