Is there a way to somehow configure spring-boot (2.1.1) actuator refresh or hikari/datasource so it reexecutes logic responsible for inmemory database (h2 for instance) creation?
At the moment after the /actuator/refresh I do not have previously created tables (hbm2ddl: create-drop or hbm2ddl: create) anymore.
There is no sample code of your implementation.
But Your problem seems to be not a problem as this is how the In-Memory Dbs are supposed to work.
These Dbs(H2,Hsql) are used for testing and not prefered for production but if you need for some small data than these are absolutely fine.
Also,
(hbm2ddl: create-drop or hbm2ddl: create)
Here, with this it will always recreate the db after the service is restarted.
change it to
(hbm2ddl: update) The syntax might not be correct.
Also taking into consideration you are using hibernate
I think actuator is meant for different things, to get an understanding of what happens in a microservice instance in a runtime mainly.
/actuator/refresh
indeed manages beans with Refresh Scope, it just recreates them without recreating the whole application context (which can be an expensive operation) if the configurations have changed (like in spring boot cloud config service).
So it has nothing to do with the lifecycle of H2 DataSource which is indeed used mainly for tests as our colleague Shubham has kindly stated, and and this makes the question even more confusing :)
Related
I'm using Spring Boot 2.7. When I run a unit test, it insists on creating the Liquibase change log table either twice for what should be an H2 in memory database. I'd like to have Liquibase log the actual JDBC URL being used. I know what the properties say, but I have an application.properties, an application-h2.properties, and sometimes Spring wants to use an in memory database even though a different in memory database is used.
Is there some property like
spring.liquibase.show-effective-jdbc-url=true?
Bonus points for telling me how to log this for regular JPA access.
Thanks,
Woodsman
There is not a flag, but the effective URL is logged at FINE level. There should be a message like Connected to USER#URL where the value for url is returned from the driver itself, not just what you gave it.
I have a spring boot project that uses flyway to insert the database structure and it works perfectly except when testing. When I run my tests I can see that the flyway sql files are executed so that works however for some reason hibernate drops and creates the database structure. This only happens when in testing so it seams as if Spring is telling Hibernate to drop-create the schema when testing.
How can I completly disable the hbm2dll?
I can understand that this is the default behaviour however it this the right thing to do? Spring should never assume that someone wants hbm2dll eneabled when testing, that should be indicated by the user not spring.
I have coded a Spring Boot based web application, which is expected to be run in WildFly server. The applications runs great, but the issue is with testing.
I have the database connections, caching and transaction management dealt by the server. Now, I need to be able to test them. While I was able to get through database connection problem through a mock JNDI connection and the transaction management, I'm not sure how to deal with testing of the caching.
One solution is to use Arquillian project. But, either this project is unable to recognize Spring Boot/ I'm doing something wrong, which is causing me pain to test the application.
Can someone please suggest on solving the issue? Below are my hibernate specific properties
spring.jpa.hibernate.naming_strategy=org.hibernate.cfg.EJB3NamingStrategy
spring.jpa.properties.hibernate.dialect=org.hibernate.dialect.SQLServer2008Dialect
spring.jpa.properties.hibernate.cache.region.factory_class=org.jboss.as.jpa.hibernate4.infinispan.InfinispanRegionFactory
spring.jpa.properties.hibernate.cache.infinispan.cachemanager=java:jboss/infinispan/container/hibernate
spring.jpa.properties.hibernate.transaction.manager_lookup_class=org.hibernate.transaction.JBossTransactionManagerLookup
spring.jpa.properties.hibernate.cache.use_second_level_cache=true
spring.jpa.properties.hibernate.show_sql=false
spring.jpa.properties.hibernate.cache.use_query_cache=false
spring.jpa.properties.hibernate.hbm2ddl.auto=none
spring.jpa.properties.hibernate.generate_statistics=true
spring.jpa.properties.hibernate.cache.infinispan.statistics=true
spring.jpa.properties.hibernate.search.default.directory_provider=infinispan
spring.jpa.properties.hibernate.search.infinispan.cachemanager_jndiname=java:jboss/infinispan/container/hibernate
I would suggest creating a separate configuration for tests. This configuration would contain a definition of a TransactionManager bean - here is an example from other post. The next step is to provide your own implementation of TransactionManagerLookup and applying it to Transport configuration - as described in the manual.
We use Spring and are integrating Flyway in a webapp that uses DispatcherServlet and runs a background DB thread.
How do control the execution flow of Spring so the migration happens before it fires up? Delaying DispatcherServlet start and Controller creation should be enough for our purposes.
You can try Spring Boot flyway support http://docs.spring.io/spring-boot/docs/current/reference/html/howto-database-initialization.html
I havent used it, but I hope it run the flyway scripts before it "starts" the "real" application. (If not it would be quite useless)
What you really want is for Flyway to migrate the database before your persistence layer comes up.
Since your controllers already depend this persistence layer, you now need to make the persistence layer itself depend on Flyway. Using XML configuration, this can be achieved using a depends-on attribute as described in the official docs.
I think afterMigrate method of Flyway Callbacks are what you are looking for.
You could have flyway in a separate factory to your spring MVC stuff. That way you can force the factory with flyway and other business logic etc to be completely created and done before the specifically MVC stuff comes up.
I would recommend you separate these two concerns in to separate factories in any case as it separates the two contexts quite nicely.
One way to achieve this is to start the business logic/flyway factory with a listener that is before the spring MVC stuff...
I am using the following versions:
Spring 3.1.1.RELEASE
Netty 3.4.0.Final
Hibernate 3.5.6-Final
Now, I have a Netty server that works fairly well - the root of the server, the pipeline factories and the base "stub" of the server that owns everything are all set up with Spring. In this stub, spring #Transactional annotations work just fine.
However, in the handlers, which are stateful and created dynamically depending on what state the user is in - #Transactional doesn't work. I'm fairly sure I understand why. I even have a "solution" - but it's not very good.
After the decoders and encoders, I add an ExecutionHandler:
pipeline.addLast("execution", new ExecutionHandler(new OrderedMemoryAwareThreadPoolExecutor(16,1000000, 1000000)));
This appears to be where the Spring transaction support is breaking. Since Spring is unaware of these threads, it can't bind any transactions to them. The classes are proxied correctly, but in debug they have no associated transactions.
My solution is crappy, and it needs to be replaced by a real solution:
Session sess = SessionFactoryUtils.getSession(getSessionFactory(), true);
That's bad because it relies on me to release the session, and it may not even be transactional, I haven't checked. It sucks in a lot of ways.
Anyway - the root of the question. Given the above tech, what's my path to getting my #Transactional notations working on the Netty handlers?
Write an ExecutionHandler that's Spring aware?
NOTE: I can't upgrade to Hibernate 4, due to lack of compatibility with Spring-Flex, used in another project in the group. Probably the same story for the Spring version, can't remember.
I suggest you create these netty's handler inside spring container and inject the service or persistence layer into the handlers so you can have these layers independence from netty and of course these are old school spring beans.