I am using spring-integration in order to connect to an external JDBC database and I want to track execution times per db connection.
Apart from using Spring AOP and wrapping my service method to measure statistics, is there any way to measure times directly in the spring-integration? Meaning to get exactly how much the database connection was used per request?
Thanks
The JDBC is used not only in Spring Integration, so it is not correct to request such a feature exactly from the Spring Integration perspective. Any other applications without any integration features should benefit from such a feature as well.
I think what you are looking for is covered by the DB metrics in Spring Boot: https://docs.spring.io/spring-boot/docs/2.1.5.RELEASE/reference/htmlsingle/#production-ready-metrics-jdbc
If you don't use Spring Boot, consider to apply the mentioned HikariCP: https://github.com/brettwooldridge/HikariCP/wiki/Dropwizard-Metrics
Otherwise you always can override execute(PreparedStatementCreator psc, PreparedStatementCallback<T> action) and wrap a super call into your own metric to measure a time for that execute() call.
Related
I have seen a few projects where developers are using RxJava with Tomcat and Mysql on Spring Boot.
As per my knowledge:
The main advantage of reactive streams is that it only creates a single thread per multiple requests, and hence database connection should also be non-blocking.
Tomcat creates threads per request.
Spring Data Jpa is blocking.
I know that there are libraries for non-blocking Relational databases (Like r2dbc).
So, I am specifically confused about the tomcat and RxJava benefits.
I would like to know the benefits of RxJava for the following scenarios:
Rest Api on tomcat with Spring data JPA (Mysql).
Rest Api on tomcat with R2dbc (MySql).
Thanks.
Benefits of Spring MVC and JPA (blocking), linear, easy to write and debug code. Slow clients may be slowing your app down.
Reactive Spring:
Small pool of threads handling many more requests - less memory consumed.
Downside: Takes time to start thinking 'reactively'.
More:
https://www.baeldung.com/spring-mvc-async-vs-webflux
Also:
https://dzone.com/articles/micronaut-mastery-using-reactor-mono-and-flux
If you rest API doesn't always go to the database you could benefit from that approach.
I am working on the micro-service developed using Spring Boot . I have implemented following layers:
Controller layer: Invoked when user sends API request
Service layer: Processes the request. Either sends request to third-part service or sends request to database
Repository layer: Used to interact with the
database
.
Methods in all of above layers returns the CompletableFuture. I have following questions related to this setup:
Is it good practice to return Completable future from all methods across all layers?
Is it always recommended to use #Async annotation when using CompletableFuture? what happens when I use default fork-join pool to process the requests?
How can I configure the threads for above methods? Will it be a good idea to configure the thread pool per layer? what are other configurations I can consider here?
Which metrics I should focus while optimizing performance for this micro-service?
If the work your application is doing can be done on the request thread without too much latency, I would recommend it. You can always move to an async model if you find that your web server is running out of worker threads.
The #Async annotation is basically helping with scheduling. If you can, use it - it can keep the code free of the references to the thread pool on which the work will be scheduled. As for what thread actually does your async work, that's really up to you. If you can, use your own pool. That will make sure you can add instrumentation and expose configuration options that you may need once your service is running.
Technically you will have two pools in play. One that Spring will use to consume the result of your future, and another that you will use to do the async work. If I recall correctly, Spring Boot will configure its pool if you don't already have one, and will log a warning if you didn't explicitly configure one. As for your worker threads, start simple. Consider using Spring's ThreadPoolTaskExecutor.
Regarding which metrics to monitor, start first by choosing how you will monitor. Using something like Spring Sleuth coupled with Spring Actuator will give you a lot of information out of the box. There are a lot of services that can collect all the metrics actuator generates into time-based databases that you can then use to analyze performance and get some ideas on what to tweak.
One final recommendation is that Spring's Web Flux is designed from the start to be async. It has a learning curve for sure since reactive code is very different from the usual MVC stuff. However, that framework is also thinking about all the questions you are asking so it might be better suited for your application, specially if you want to make everything async by default.
I am trying to understand the transaction management in Spring, and I have got some doubts.
I read a bit about transaction management in EJB world, which can be CMT or BMT. For CMT, as per the documentation, it is Application server (e.g. JBOSS) which manages the transaction.
Now, coming to Spring transaction management, and considering using Web container only (Apache Tomcat), how does this work?
Does Spring have its own transaction management with capability of handling local transaction and global transaction (which works with 2 phase commit). Do the actual support need to come by the underlying container (in this case Apache tomcat) or support from framework is sufficient?
I am not clear how all these pieces fit together.
Can anyone help me understand this?
Spring doesn't include any kind of transaction capability of its own, it only provides ways to connect to transaction functionality provided by the container or by standalone libraries.
If you run your application on Tomcat and don't provide any transaction manager libraries like bitronix, then you get only local jdbc transactions provided by the servlet container.
When you read the bullet points at https://docs.spring.io/spring/docs/4.2.x/spring-framework-reference/html/transaction.html notice it says spring is providing abstractions, that means it is providing access through its own apis and using aop to make transactions nonintrusive, but not providing any implementation of transactional functionality. It's facilitating gluing things together, which is the main thing spring does.
Is it possible to use transactions when Neo4j is used as standalone server? I am using functions from my Spring repositories, and probably each of them is executed as a separate transaction, but I would like to merge them into one. Is it possible to do this?
SDN doesn't support remote transactions (which only work with the transactional endpoint and Cypher) yet.
So the option you have to speed your operation up is to move the processing of the SDN entities into the server an expose a domain level REST API to your clients (either with Jersey, or SD-REST).
see: http://inserpio.wordpress.com/2014/04/30/extending-the-neo4j-server-with-spring-data-neo4j/
I am willing to create an example(code) using Spring in which business logic to be distibuted across different servers like JBoss or Glassfish and still under one transaction? First of all is this possible in Spring. I know using EJB has this option. Likewise do we have a similar technique in Spring also? I am looking for Synchronous communication approach and not using asynchronous message oriented middleware. Any help/pointer appreciated.
Thanks
Prakash
Spring has support for RMI or provides its own remoting mechamism HttpInvoker but according to the doc they don't provide any remote transaction propagation.
Similar questions:
Spring Distributed Transaction Involving RMI calls possible?
Transaction propagation in multiple servlet context with multiple data source