We would like to set the flush mode of Hibernate to MANUAL.
We use the spring property: spring.jpa.properties.org.hibernate.flushMode. This property works fine for COMMIT, ALWAYS and AUTO. MANUAL is also accepted and correctly parsed (as we saw during code debugging).
Sadly when we check the flush mode with
((org.hibernate.Session) entityManager).getHibernateFlushMode()
we see that first three options work fine but if we set to MANUAL the flush mode in the session is AUTO.
Is this a bug or a feature and how can we get around it?
Spring Boot version: 2.6.4
Hibernate version: 5.6.5
Further investigation showed that a method annotated with #Transactional changes flush mode from MANUAL to AUTO.
We changed to #Transactional(readOnly=true) (which was in our case even more correct) and solved the problem.
Related
I'm migrating my existing Spring Boot 2.1.x application to 2.6.x. I want the following behavior (for integration tests which uses embedded H2 database), which is working fine in 2.1.x (obviously) but I'm struggling to achieve the same behavior in 2.6.x.
Create DDL automatically (without any custom SQL script)
Execute custom DML (data.sql)
Initialize beans which implements InitializingBean and use data populated in step #2. Eg. Cache database table records for application to use later
Problem #1 (Solved)
2.6.x was no longer created DDL automatically by default. So adding below properties explicit seemed to be the solution.
spring.jpa.generate-ddl = true
spring.jpa.hibernate.ddl-auto = create-drop
This solves Step #1 with 2.6.x.
Problem #2 (Solved)
Starting from 2.5, Boot was running scripts in data.sql before Hibernate is initialized. Hence, data.sql was failing. To make Boot wait for DDL creation to complete, adding below property seemed to be the solution.
spring.jpa.defer-datasource-initialization = true
This solves *Step #2 with 2.6.x.
Problem #3 (Need solution)
Seemingly because of setting spring.jpa.defer-datasource-initialization to true, Step #3 is happening before Step #2 i.e. in 2.6.x. This cause beans to initialize with empty database tables e.g. Cache is populated with no entries. These are causing my tests to fail.
I played with properties like spring.jpa.defer-datasource-initialization, spring.data.jpa.repositories.bootstrap-mode and spring.sql.init.mode to workaround this without any luck.
From Spring DB Initialization docs, Spring boot DB initialization using Spring JDBC supports
feature Fast fail - that means if there are any issues in DB init script or migration scripts then Spring boot Context initialization failed. as result Spring boot server won't start.
now can we have this functionality when we use Advanced DB Migration tool like liquibase?
Spring Docs Doesn't say anything about this in liquibase section. Does this feature only works in Spring JDBC initialization?
whenever there is an issue in your liquibase script, application won't start because datasource is not properly initialised.
You can specify the desired behaviour using 'Preconditions'.
On default, it actually will fail fast, but you can overwrite it (example using SQL syntax):
-- preconditions onFail:WARN onError:WARN
Available parameters:
HALT: Immediately halt the execution of the entire changelog. [DEFAULT]
CONTINUE: Skip over the changeset. Execution of the change set will be
attempted again on the next update. Continue with the changelog.
MARK_RAN: Skip over the changeset, but mark it as executed. Continue
with the changelog. WARN Output a warning and continue executing the
changeset / changelog as normal.
see https://docs.liquibase.com/concepts/advanced/preconditions.html
I am working on a Spring Boot (2.0.2.RELEASE) application. Recently I enabled transaction management and created a DataSourceTransactionManager in the app configuration. We are using Spring Data JPA with Hibernate.
I noticed some time later that many (but not all) saves were not actual happening, but all log entries state everything was fine. Only affected saves were made by a Quartz job. Some of them were successful, but most of them not. No errors in the logs.
I since removed the transaction manager and now everything works as expected.
I assume now that DataSourceTransactionManager isn't meant to be used with JPA or Hibernate. I still don't know what to use and why this error happened.
Any help is appreciated.
Prior to Spring Boot v1.5.11, the following worked for referring to a file called auth.json in src/main/resources:
spring.cloud.gcp.credentials.location=auth.json
Starting with v1.5.11 and continuing through into 1.5.12, the above results in a FileNotFound exception. But the following works:
spring.cloud.gcp.credentials.location=classpath:auth.json
What changed in Spring Boot 1.5.12 (or its underlying dependencies) that was responsible for this?
This was caused by a fix to another issue and is being tracked via another reported instance here: https://github.com/spring-projects/spring-boot/issues/12786
Practitioners hitting this behavior may either update their implementation in an appropriate way (e.g., in our sanitized sample, it would be to prefix the property with "classpath:") or to wait to see if further resolution (that doesn't regress the other fix that caused this) is possible.
h/t #Stephane-Nicoll and Andy Wilkinson.
In openJPA 2.4, if I set :
<property name="openjpa.QueryCache" value="true"/>
but DO NOT SET openjpa.RemoteCommitProvider property, I get the following error :
org.apache.openjpa.util.UserException: You have attempted to use a RemoteCommitListener without also specifying a RemoteCommitProvider. In order to use a remote commit listener, you must configure a remote commit provider to use through the openjpa.RemoteCommitProvider configuration property.
This configuration used to work in openJPA 1.X
Does anyone know if QueryCache absolutely requires a openjpa.RemoteCommitProvider or does this look like a bug in openJPA ?
The documentation mentions that openjpa.RemoteCommitProvider is required for openjpa.DataCache but it doesn't mention that for openjpa.QueryCache
I think the problem you've encountered is an oddity of a configuration problem. From what I can tell, you must have the QueryCache enabled, but not the DataCache.? If that is not true, please ignore the rest of my post.
From what I recall when you enable openjpa.DataCache the runtime automatically configures a RemoteCommitProvider for you. The RCP is required when using the DataCache/QueryCache. In your case if you only have the QueryCache enabled, the RCP doesn't get auto configured.
I'm still scratching my head why you are configuring the QueryCache without the DataCache? This is a very odd use case as with this setup it is very unlikely that you'll ever have a cache hit and you're paying the price of a cache that isn't helping you.