Skip to content
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

Support for statement interceptors #23

Open
gauravrmazra opened this issue Dec 22, 2015 · 6 comments
Open

Support for statement interceptors #23

gauravrmazra opened this issue Dec 22, 2015 · 6 comments

Comments

@gauravrmazra
Copy link

I am curious to know if this API can provide interceptor support. I want to execute some piece of code before and after every jdbc query. The support I am thinking of is the one provided by MySQL (StatementInterceptor).

Can I expect something similar to it in future?

@komu
Copy link
Member

komu commented Jan 11, 2016

Hi! Sorry for the delayed answer.

Currently there's no support for interceptors at the statement level.

If you implement your own TransactionManager, Dalesbred will call either withCurrentTransaction or withTransaction whenever it is going to execute a statement. So you could do whatever you wish to do and then delegate the calls to the real TransactionManager. However, Dalesbred will not pass you the Statement it's about to execute, so this might not be enough for your needs.

I'll consider adding this in a future version, but I'd like to know more about your specific use case. Perhaps there's an even better way to support what you need to do?

@komu komu changed the title Can you provide support for interceptors around the API? Support for statement interceptors Jan 11, 2016
@gauravrmazra
Copy link
Author

The idea behind this is to measure the execution time of SQL basically for tracing purposes.
There are some built-in support available in MySQL JDBC driver and with Apache JDBC connection pool but the wiring/using it is not elegant. We are using Dalesbred in one of our project and I was looking for this kind of support. Now, I wrapped Database class to provide this sort of support but looking forward for some interceptor kind of feature.

@komu
Copy link
Member

komu commented Jan 11, 2016

OK, then you might be happy to find out that Dalesbred already logs all queries. You just have to bump up the log level of org.dalesbred.Database-category. Dalesbred logs using java.util.logging to avoid extra third-party dependencies, but it's possible to redirect those using jul-to-slf4j or similar adapter to logging framework of your choice.

@gauravrmazra
Copy link
Author

Tracing db call means to instrument dalesbred for Spring Cloud Sleuth (distributed tracing system) or any Distributed tracing system like htrace, pinpoint, xtrace.

@komu
Copy link
Member

komu commented Jan 11, 2016

Right, I suspected something like this. This is not prettiest solution, but you should be able to write your own java.util.logging.Handler to get callbacks whenever Dalesbred logs the queries. You could then parse the time and SQL from the message and forward them to your tracing framework.

Of course a real callback would be nicer in the future, but this would be something you can do today.

As a related note, it would be nice to have a JDBC-driver that would adapt other JDBC-drivers and add features like tracing or simulated extra latency etc. Then you could use that with any persistence framework to diagnose and test your system. But I don't believe such a thing exists. :(

@gauravrmazra
Copy link
Author

java.util.logging.Handler will not solve the purpose.

Yes, Driver/DataSource level support is something which is more elegant as well as complex to maintain and test.

Appreciate for your help.

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

No branches or pull requests

2 participants