The getMetaData() method on DualConnection can be called at anytime during the lifetime of the connection.
In the current behaviour, when getMetaData() 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 getMetaData() 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 getMetaData() method on DualConnection to use the read connection but makes the following trade off.
If getMetaData() is called right before a DML query, the meta data returned will be for the read connection rather than the write. This may be problematic for the caller however in most cases, the meta data from both the read and write connections will largely be the same (except for connection URL).
The
getMetaData()method onDualConnectioncan be called at anytime during the lifetime of the connection.In the current behaviour, when
getMetaData()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
getMetaData()before anyexecutemethods, 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
getMetaData()method onDualConnectionto use the read connection but makes the following trade off.If
getMetaData()is called right before a DML query, the meta data returned will be for the read connection rather than the write. This may be problematic for the caller however in most cases, the meta data from both the read and write connections will largely be the same (except for connection URL).