This reference documentation from spring.io states claims that Spring Data JDBC supports a #Lock annotation.
Spring Data JDBC supports locking on derived query methods. To enable locking on a given derived query method inside a repository, you annotate it with #Lock.
However, I am unable to find such an annotation in the spring-data-jdbc library. There is one in the spring-data-jpa, but we use data-jdbc.
Is there a mistake in the documentation or am I missing something?
It's org.springframework.data.relational.repository.Lock.
As you can see it is in Spring Data Relational which is the basis for both Spring Data R2DBC and Spring Data JDBC.
Related
Can Spring Batch use no-sql database (e.g. firestore, mongodb, etc.) to store batch metadata? If yes, can you share sample?
It can, but it does not provide an implementation yet. We have a feature request for that here: https://github.com/spring-projects/spring-batch/issues/877.
That said, it is a matter of implementing a single interface: JobRepository. Otherwise, you can implement the 4 DAOs required by Spring Batch using your NoSQL database (JobInstanceDao, JobExecutionDao, StepExecutionDao, ExecutionContextDao) and use them with the provided SimpleJobRepository.
I'm migrating a system that used to be written in Jdbc Templates to Spring Data JPA. Before, we used to write the SQL queries ourselves, but now that we're modernizing our system, we're going to use Spring Data JPA for this. Due to restrictive factors, i can't implement a database migration framework, such as flyway and liquidbase. Is there any way i can implement those using what i have on Spring JPA?
Im thinking about using QueryDSL in my project where I am already using Spring Data. I am programming a microservice inclidung a REST-Interface.
What are the main differences between Spring Data and QueryDSL? What are the big benefits of using QueryDSL instead of Spring Data?
Querydsl and Spring Data go along well. While both deal with the domain of persistence they have very different goals.
Querydsl provides a type-safe query API.
Spring Data provides a consistent API to accessing persistent stores, inspired by the ideas of Domain Driven Design, without getting in the way of the user and how she wants to formulate queries.
Therefore there exists an extension point to combine Spring Data and Querydsl and you can always implement non-standard queries using Querydsl if they go beyond, what can be easily formulated using the build in Spring Data repositories.
In my project, we are upgrading an old J2EE application to Java EE 6.
Since the business logic is quite complex, we want to retain the EJB + DAO code as much as possible. The old code uses plain JDBC for database persistence.
But in our new/upgraded application, we plan to use JPA.
We would like to use JPA for all the read operations on database and use JDBC for the writes (inserts/updates/deletes). Is this possible in the same transaction?
For example:
obtain an Entity Manager reference and read an employee record from the database (employee entity) using entity manager find (or a named query)
convert the entity instance to a POJO
update the POJO
perform some business logic on the POJO (reuse old code as-is)
create a JDBC connection and use a prepared statement to update the employee record in database (reuse old code as-is)
Questions:
If I open 2 separate connections to the database - one from JPA and another from JDBC, will it still be in the same transaction (since app server manages the JTA transaction)?
What are the potential issues with this approach?
Since I am updating the database via JDBC, the entity in persistence context will not be in sync with the database. How to handle caching in such cases?
I looked at the following related threads, but I would like to know more in detail.
Combining JPA and JDBC actions in one transaction
Hibernate and JDBC in one transaction
We have a requirement for building a database crawler. The application parses the tnsnames, connects to each database and retrieves some information like version, accounts, etc. We are trying to use JPA across the other parts of the application and to persist this data into the application's database.
So far, I only see creating an EntityManagerFactory programmatically for every database. Is there any other options?
We are using Spring, are there any benefits that Spring brings to the table in this scenario?
Thanks
JPA is clearly not the right tool for this job. JPA allows creating functional entities mapping a well-know database schema. Your tool doesn't know anything about the schemas and tables it will find. There could be 0 tables or 5000, with completely unknow names.
You need a much lower-level API to do what you want, like JDBC.
You could use JPA to store the results of your crawlings in a single schema, though.