Is there a way to speed up Hibernate Schema Validation? - performance

I am running a hibernate schema validation at the server startup. I also have a test case that can trigger the schema validation.
This is done by setting the following property on hibernate configuration.
hibernate.hbm2ddl.auto=validate
I have a about 3600 entities that need to be validated, but the schema validation is taking somewhere between 20 and 30 minutes. I have debugged through the code, and most of the time taken is within the hibernate framework.
I was wondering if there is a way to speed up validation (eg. parallel processing of the tables) or via some other properties.

Related

What are the ways to listen to the success or failure of transactions when working with Spring (spring boot, spring data)

When working with transactions, sometimes there is a need to do an audit of working with a business object (crud operations when working with tables). At the same time, you need to do this in real time and enter this record in the database :
the name of the user,
the business object with which the work is performed,
the success or rollback of the transaction with the fixing of the reason,
the time of the event occurrence.
Share ways to solve this problem, as you do when working with Spring data.
Do you create your own custom aspects ?
Give examples, if you don't mind .

Spring boot app, need to set a database session variable before every transaction

I have a spring boot application that uses Hibernate/JPA entities. I need to run a bit of SQL to set a database session variable prior to each transaction. This session variable controls row level security at the database layer and so the SQL will use a web session parameter which I can retrieve from the spring web session context. I will need this bit of sql to run essentially before every transaction.
I'd like to be able to do this in a way that does not effect every additional piece of business logic. i.e. I'd rather not have to call the method manually from every repository class.
I saw the ConnectionPreparer class in the spring-data-jdbc-ext project (https://github.com/spring-projects/spring-data-jdbc-ext/blob/master/spring-data-jdbc-core/src/main/java/org/springframework/data/jdbc/support/ConnectionPreparer.java). However it appears this class is only called when the connection is first instantiated, not prior to every transaction.

ResultSet caching in Spring-boot Camel SQL

I have implemented a Spring-boot Camel batch application running every 5 mins which is using camel-sql component to query some data from table. I am using java DSL implementation and configuring my routing endpoints inside RouteBuilder.configure. Everything is working fine as expected. But now as part of optimization I am planning to cache some of the query results which are not changing frequently like some global configuration tables, location timezone table etc.
I have gone through Camel EHcache documentation, but not getting the right understanding of the standard way of implementation.
My expectation is like the following
Suppose my routing is,
from(timercomponent)
.to(SqlComponent1)
.process(ResultProcessor::processResult1)
.to(SqlComponent2) // needs to be cached
.process(ResultProcessor::processResult1)
....
...
I don't want SqlComponent2 to hit the DB always and it should use a cached value from the first execution with an expiry time of 1 week.
Also I just wanted to know which is the best cache implementation to be used in this scenario.
What do you mean? Ehcache or something else? Or how to configure the Ehcache cache?
From the Ehcache point of view, you will need a Cache using a 1 week TTL expiry.
Then, it's been a while I've implemented caching with Camel but the doc seems to say that an Ehcache idempotent repository should do the trick.

Transaction management in database when two spring boot application trying to access the same record

Two spring boot applications are connected to the common database.
I just wanted to know, how to handle the transaction if both the application try to update the record at the same time?
Since you seem to use JPA (via Spring Data JPA) there isn't much to handle.
The database itself will prevent two transactions to update the record at the same time. So one will always be first.
If you use optimistic locking (which is the default with JPA) the second transaction will notice the modified row and rollback.
Without that the second transaction will simply overwrite the changes with it's own changes.

How does spring.jpa.hibernate.ddl-auto property exactly work in Spring?

I was working on my Spring boot app project and noticed that, sometimes there is a connection time out error to my Database on another server(SQL Server).
This happens specially when I try to do some script migration with FlyWay but it works after several tries.
Then I noticed that I didn't specify spring.jpa.hibernate.ddl-auto in my properties file. I did some research and found that it is recommended to add
spring.jpa.hibernate.ddl-auto= create-drop in development.
And change it to: spring.jpa.hibernate.ddl-auto= none in production.
But I didn't actually understand how does it really work and how does hibernate generate database schema using create-drop or none value. Can you please explain technically how does it really work, and what are recommendations for using this property in development and on a production server.
Thank you
For the record, the spring.jpa.hibernate.ddl-auto property is Spring Data JPA specific and is their way to specify a value that will eventually be passed to Hibernate under the property it knows, hibernate.hbm2ddl.auto.
The values create, create-drop, validate, and update basically influence how the schema tool management will manipulate the database schema at startup.
For example, the update operation will query the JDBC driver's API to get the database metadata and then Hibernate compares the object model it creates based on reading your annotated classes or HBM XML mappings and will attempt to adjust the schema on-the-fly.
The update operation for example will attempt to add new columns, constraints, etc but will never remove a column or constraint that may have existed previously but no longer does as part of the object model from a prior run.
Typically in test case scenarios, you'll likely use create-drop so that you create your schema, your test case adds some mock data, you run your tests, and then during the test case cleanup, the schema objects are dropped, leaving an empty database.
In development, it's often common to see developers use update to automatically modify the schema to add new additions upon restart. But again understand, this does not remove a column or constraint that may exist from previous executions that is no longer necessary.
In production, it's often highly recommended you use none or simply don't specify this property. That is because it's common practice for DBAs to review migration scripts for database changes, particularly if your database is shared across multiple services and applications.
In Spring/Spring-Boot, SQL database can be initialized in different ways depending on what your stack is.
JPA has features for DDL generation, and these can be set up to run on startup against the database. This is controlled through two external properties:
spring.jpa.generate-ddl (boolean) switches the feature on and off and is vendor independent.
spring.jpa.hibernate.ddl-auto (enum) is a Hibernate feature that controls the behavior in a more fine-grained way. See below for more detail.
Hibernate property values are: create, update, create-drop, validate and none:
create – Hibernate first drops existing tables, then creates new tables
update – the object model created based on the mappings (annotations or XML) is compared with the existing schema, and then Hibernate updates the schema according to the diff. It never deletes the existing tables or columns even if they are no more required by the application
create-drop – similar to create, with the addition that Hibernate will drop the database after all operations are completed. Typically used for unit testing
validate – Hibernate only validates whether the tables and columns exist, otherwise it throws an exception
none – this value effectively turns off the DDL generation
Spring Boot internally defaults this parameter value to create-drop if no schema manager has been detected, otherwise none for all other cases.
"spring.jpa.hibernate.ddl-auto= create-drop" means that when the server is run, the database(table) instance is created. And whenever the server stops, the database table instance is droped.
Also depending on spring.jpa.hibernate.ddl-auto the DML files feature is enabled
DDL and DML
It is worth to understand the difference between them.
Data Definition Language(DDL) - related to database schema creating
Data Manipulation Language(DML) - related to importing data
Basically there are 3 types of database schema creating(DDL) and importing data(DML):
Using Hibernate
Using Spring JDBC SQL scripts
Using high level tools like Flyway/Liquibase
This topic covers Hibernate and it's DDL (first option), but it is worth to mention Hibernate DML files feature that enabled if spring.jpa.hibernate.ddl-auto is create or create-drop
That means import.sql in the root of the classpath will be executed on startup by Hibernate. This can be useful for demos and for testing if you are careful, but probably not something you want to be on the classpath in production. It is a Hibernate feature (nothing to do with Spring).
Also here is a table that explains spring.jpa.hibernate.ddl-auto and whether the import.sql can be used depending on spring.jpa.hibernate.ddl-auto value specified:
spring.jpa.hibernate.ddl-auto
Create schema from entities
import.sql
create
true
true
update
update schema from entities
false
create-drop
true
true
validate
false
false
none
false
false
Also some extra information about different types of DDL amd DML can be found in Spring docs
For the Propertie of JPA/Hibernate
spring.jpa.hibernate.ddl-auto value should be create, update, create-drop not other then it will give an exception, where the correct meaning for these value -
Create : when the server will start all entity will be newly created
Update : when the server will start container will find which entities are update and which all are newly created the same thing will happen inside database as well old table will update as per the entity and newly table will created
Create-drop: when the server will start then auto all entity will crete and when the server will stop all the entities will auto remove from database
none : it means database ddl will not impact from back-end application Note: Production environment always set with none value

Resources