-
Notifications
You must be signed in to change notification settings - Fork 1k
make jdbc indy-ready #14764
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
make jdbc indy-ready #14764
Conversation
…nstrumentation into indy-jdbc
…nstrumentation into indy-jdbc
…nstrumentation into indy-jdbc
…nstrumentation into indy-jdbc
| DbRequest request; | ||
| if (sql != null) { | ||
| request = DbRequest.create(statement, sql); | ||
| } else if (preparedStatement != null) { | ||
| Map<String, String> parameters = JdbcData.getParameters(preparedStatement); | ||
| request = DbRequest.create(preparedStatement, parameters); | ||
| } else { | ||
| // batch | ||
| request = createBatchRequest(statement); | ||
| } |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
perhaps it would be better for start to accept Supplier<DbRequest> so that the request creation could be moved to startStatement etc.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'll try to do that, but I see two potential issues:
- extra allocation due to having to create an supplier instance on each call
- we might not be able to use lambdas unless the instrumented bytecode is java 8 or later
We could however maybe use an enum rather than an heuristic based on null arguments to split the 3 types of calls.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
extra allocation due to having to create an supplier instance on each call
This isn't really an issue because we need to create a bunch of objects for each span. I guess you could try you could try subclassing the JdbcAdviceScope If you wish to avoid the supplier or use a stateless lambda, but probably not worth the effort.
we might not be able to use lambdas unless the instrumented bytecode is java 8 or later
that is not an issue since the code is inside JdbcAdviceScope
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I was thinking of pushing the Supplier creation directly into the advice, but you are right keeping it JdbcAdviceScope already makes things easier to read. Once everything is running with indy advices we could even directly remove those 3 intermediate methods that are called from advices.
…nstrumentation into indy-jdbc
Part of #13031 for jdbc instrumentation