Consider extending ConnectionFactory with create(ConnectionDefinition)

[mp911de]

With the growing flexibility and operation modes how databases are operated, there are use-cases (e.g. clustering, read-only mode) where these details can be passed directly to the connection retrieval.

With the current arrangement, a read-only flavor can be only passed through extensible transaction definitions, if at all (#159). Systems that manage transactions for applications (e.g. transaction managers) typically allocate a connection on transaction start (or when the unit of work begins) and then they prepare the connection according to the needs. In many cases, preparation requires a few roundtrips to the database.

Introducing connection definitions would allow specification of such details upfront so a driver can immediately return a connection that is e.g. suitable for read-only operations by utilizing replica connections. Another case would be transaction level isolation.

Introducing connection definitions would also introduce the constraint that some attributes may not be changed afterwards as e.g. a read-only-replica connection cannot be routed back to the writable primary server.

[mp911de]

A parameterized ConnectionFactory.create introduces a lot of complexity for connection pools as pooled connection compliance to the requested ConnectionDefinition is unknown. Either the pool needs to request a new (unpooled) connection or maintain separate sub-pools. Neither is a good option.