Skip to content

jdbc: Pooled statements support #181

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
nicktorwald opened this issue May 6, 2019 · 5 comments · Fixed by #204
Closed

jdbc: Pooled statements support #181

nicktorwald opened this issue May 6, 2019 · 5 comments · Fixed by #204
Assignees
Labels
Milestone

Comments

@nicktorwald
Copy link

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.

@nicktorwald nicktorwald added this to the JDBC MVP milestone May 6, 2019
@Totktonada
Copy link
Member

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
Copy link
Author

nicktorwald commented May 13, 2019

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.

The poolable statement makes sense in cases when the server supports prepared statements explicitly, say SQL PREPARE-EXECUTE-RELEASE or 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.

Should we file another issue to tarantool to support acquring metainfo (results types) before execution of a statement?

Do you mean ParameterMetedata? If so, there is #173 and yes it requires such requests to the server.

@Totktonada
Copy link
Member

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 MVP milestone.

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
Copy link
Author

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:

It is up to the statement pool manager as to whether the hint is used.

This issue is more about performance and doesn't impact on JDBC functionality.

@Totktonada
Copy link
Member

Okay. Let's implement it just as API w/o considering the hint for now.

nicktorwald added a commit that referenced this issue Jul 5, 2019
Implement corresponding API related to poolable statements. This hint
is ignored and used to be compatible with the API.

Closes: #181
@nicktorwald nicktorwald self-assigned this Aug 3, 2019
nicktorwald added a commit that referenced this issue Aug 7, 2019
Implement corresponding API related to poolable statements. This hint
is ignored and used to be compatible with the API.

Closes: #181
nicktorwald added a commit that referenced this issue Aug 7, 2019
Implement corresponding API related to poolable statements. This hint
is ignored and used to be compatible with the API.

Closes: #181
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants