The getClientInfo() method on DualConnection can be called at anytime during the lifetime of the connection.
In the current behaviour, when getClientInfo() is called right after the construction of a DualConnection, it will pinned the connection to always use the write instance. During heavy read-only operations, this can lead to unintended saturation of the writer instance when the reader instances still have capacity.
This is mostly problematic for telemetry agents such the OpenTelemetry Java agent as these agents will always call getClientInfo() before any execute methods, pinning the connection to use the write instance even when the connection will only ever be used for reads.
This PR changes the behaviour of the getClientInfo() method on DualConnection to use the read connection but makes the following trade off.
If getClientInfo() is called right before a DML query, the properties returned will be for the read connection rather than the write. This may be problematic for the caller however in most cases, the properties from both the read and write connections will largely be the same with some variances.
This same issue as the one described in https://github.com/atlassian-labs/db-replica/pull/167 however this time it's the
getClientInfo()method.The
getClientInfo()method onDualConnectioncan be called at anytime during the lifetime of the connection.In the current behaviour, when
getClientInfo()is called right after the construction of aDualConnection, it will pinned the connection to always use the write instance. During heavy read-only operations, this can lead to unintended saturation of the writer instance when the reader instances still have capacity.This is mostly problematic for telemetry agents such the OpenTelemetry Java agent as these agents will always call
getClientInfo()before any execute methods, pinning the connection to use the write instance even when the connection will only ever be used for reads.This PR changes the behaviour of the
getClientInfo()method on DualConnection to use the read connection but makes the following trade off.If
getClientInfo()is called right before a DML query, the properties returned will be for the read connection rather than the write. This may be problematic for the caller however in most cases, the properties from both the read and write connections will largely be the same with some variances.