Is there a pitfall to using two Hikari connection pools pointing to the same db? - spring-boot

In a Spring Boot application using Log4j2, I have setup a DataSource via yaml-configuration. But since Log4j2 needs a connection pool already in the startup phase for its JDBC Appender, a second data source must be provided separately. This results in the application having two connection pools running, both writing to the same database.
My first question is:
Are there any concerns about this setup, or is this the normal approach anyway?
Alternatively, the following setup would come to mind: we programmatically initialize the DataSource, so that we have access to it. Further on, we can then programmatically extend the existing Log4j2 configuration that doesn't have a JDBC Appender yet. By doing so we can pass the pooled DataSource that we also use for the application itself.
My second question is therefore:
Are there any caveats to using the same DataSource for both the application and the Log4j2 logging framework?
Many thanks for any information that helps to clarify the situation.

Related

Is it possible to disable a Spring Boot datasource configuration based on unavailability of a connection to a DB

We have an application that uses several data sources. A DB underlying one of those data sources is down at the moment: IOError. Network adapter couldn't establish the connection & Socket read timed out.
Is there an annotation (or other means) of configuring Spring Boot such that it bypasses the culprit data source and still starts up: the DB is not essential in current development work. spring.datasource.continue-on-error=true doesn't seem to work. This is Spring 2.2.2.RELEASE.
using multiple datasource, so when your apps fail at start up your apps still work, i mean using memory db / sqlite to handle fail at connection error...

How to use Spring transactions with plain old jdbc connection without Spring jdbc template?

We have an old EJB based web application which we are supposed to migrate into Spring boot. For database connectivity, it is a plain old jdbc connection approach as of now.
We want to use Spring transactions and remove EJB transactions but willing to keep plain old jdbc connectivity same. In short we don't want to make changes in our DAO layer to convert plain old jdbc to Spring JdbcTemplate.
Please note that we have our own connection pooling algorithm and we create connection object and close it in the pool.
Along with this we want our application to be multi-tenant that can work with multiple databases on the basis of 'tenantID' that we will provide.
I actually tried to implement this but it is not working. I had to manually do con.commit(); and con.rollback();
Is there any way to use Spring transactions with plain old jdbc connectivity with above scenario?

Transaction management in Spring: Does support come from Spring or container?

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.

Does Spring JDBC supports XA connection pools (for example, Oracle UCP)?

I'd like to add XA connection pool to my Spring based application, specifically Oracle UCP. This pool works on XADataSource and XAConnection objects. Standard DataSource.getConnection(...) methods are not supported.
Trying working with that pool (that I am able to successfully set up in Spring) I am getting an error related to the fact that getConnection(...) methods invoked by JdbcTemplate are disabled and should not be used. I am just wondering whether any of Spring JDBC classes are able to work with XADataSource and XAConnections? Probably there are another ways to use Spring with XA connection pools? Will appreciate any advices on that topic.
Just for those who may experience similar problems - Spring doesn't support directly XA connection pools (through native XADataSource.getXAConnection(...) methods). You need to write a kind of wrapper utilizing DatSource.getConnection(...) methods.

Spring Data when does it connect to the database

I have been researching Spring Data Rest especially for cassandra and one of the questions my coworkers and I had was when does Spring Data connect to the database. We don't always want a rest controller to connect to the database so when does spring establish a connection if say we had a class extend the CRUDRepository? Does it connect to the database during the start of application itself? Is that something we can control?
For example, I implemented this example on Spring's website:
https://spring.io/guides/gs/accessing-data-rest/
At what point in the code does spring connect to the database?
Spring will connect to the DB as soon as the Datasource get initialized. Basically, Spring contexts will become alive somehow (Web listeners, manually calling them) and start creating beans. As soon as it reaches the Datasource, connection will be made and the connection pool will be populated.
Of course the above is based on a normal out of the box configuration and everything can be setup up to your taste.
So unless, you decide to control the connections yourself, DB connections will be sitting there waiting to be used.
Disagree with the above answer.
As part of research i initiated the datasource using a bean configuration and then changed my database password(not in my spring application but the real db username password)
The connection stays for a while and then in some point of time (maybe idle time) it stops working and throws credential exception.
This is enough to say the JPA does not keep the connection sitting and waiting to be used but uses some mechanism to occupy/release the db connection as per the need.

Resources