Repository navigation
jdbc: Pooled statements support #181
Description
Need to implement a statement cache to reuse same queries
Statement.isPoolable and Statement.setPoolable methods
Note: By default, a Statement is not poolable when created, and a PreparedStatement and CallableStatement are poolable when created.
Activity
Totktonada commentedon May 12, 2019
Seems to be connected with tarantool/tarantool#2592 . Don't sure whether it is worth to really hold a statement pool if it will be on the tarantool side and will be transparent. However we should support the API. Should we file another issue to tarantool to support acquring metainfo (results types) before execution of a statement?
nicktorwald commentedon May 13, 2019
The poolable statement makes sense in cases when the server supports prepared statements explicitly, say SQL
PREPARE-EXECUTE-RELEASEor using binary protocol (i.e. MySQL prepared statements or Postgres prepared statements). The connector will send statement label, received from the server, instead of a full query string. And these labels (+ possibly a result set metadata) are cached/pooled by the connector.Transparent prepared statement support looks like a half of victory in pursuit of performance where the connector cannot send/parse fewer bytes and manage server prepared statements lifetime.
Do you mean
ParameterMetedata? If so, there is #173 and yes it requires such requests to the server.Totktonada commentedon May 20, 2019
If the API is mandatory (or worth to implement because of another reason) we should support the API, but use non-pooled statements under hood. This is the case for
JDBC MVPmilestone.Otherwise it should be either moved to
JDBC + transactions(and marked as blocked by corresponding issue in tarantool) or closed if this is not planned to be supported on the tarantool side. I'll elaborate this part.@nicktorwald Can you please investigate whether it the API is mandatory / important?
nicktorwald commentedon May 20, 2019
This is mandatory but this is also just a hint to the driver. At present, we can support it but ignore the hint.
API says:
This issue is more about performance and doesn't impact on JDBC functionality.
Totktonada commentedon May 20, 2019
Okay. Let's implement it just as API w/o considering the hint for now.
Poolable statement hint
Poolable statement hint
Poolable statement hint