I'm using Spring Boot (1.4.4.REALEASE) with Spring Data in order to manage a MySql Database. I've got the following case:
We update one revision performed in one equipment using the RevisionService.
RevisionService saves the revision and calls the EquipmentService to update the equipment status.
The updateEquipmentStatus does a call to a Db stored procedure in order to evaluate the equipment with its revisions altogether and update the field.
I've tried some options but don't achieve to get the updated status for the equipment. The updateEquipmentStatus method keeps writing the previous status for the equipment (not considering the current revision being stored in the transaction). The code is written this way:
RevisionService
#Service
public class RevisionService{
#org.springframework.transaction.annotation.Transactional
public Long saveRevision(Revision rev){
//save the revision using JPA-Hibernate
repo.save(rev);
equipmentService.updateEquipmentStatus(idEquipment);
}
}
EquipmentService
#Service
public class EquipmentService{
#org.springframework.transaction.annotation.Transactional
public Long updateEquipmentStatus(Long idEquipment){
repo.updateEquipmentStatus(idEquipment);
}
}
EquipmentRepo
#Repository
public interface EquipmentRepo extends CrudRepository<Equipment, Long> {
#Modifying
#Procedure(name = "pupdate_equipment_status")
void updateEquipmentStatus(#Param("id_param") Long idEquipment);
}
As far as I understand, as both methods are annotated with Spring's transactional, the updateEquipmentStatus method should be executed in the scope of the current transaction. I've also tried with different options for the #Transactional annotation from updateEquipmentStatus, such as #Transactional(isolation=Isolation.READ_UNCOMMITTED) (which shouldn't be required, because I'm using the same transaction) and #Transactional(propagation=Propagation.REQUIRES_NEW), but keeps not considering the current status. That's how my stored procedure is saved into the MySql DB:
CREATE DEFINER=`root`#`localhost` PROCEDURE `pupdate_equipment_status`(IN `id_param` INT)
LANGUAGE SQL
NOT DETERMINISTIC
MODIFIES SQL DATA
SQL SECURITY DEFINER
COMMENT ''
BEGIN
/*Performs the update considering tequipment and trevision*/
/*to calculate the equipment status, no transaction is managed here*/
END
I also want to clarify that if I execute some modification in the equipment itself (which affects only tequipment), the status is being properly updated. InnoDb is the engine being used for all the tables.
UPDATE
Just changed the repo method to use a nativeQuery instead and the same problem keeps happening, so the Db procedure being involved should be discarded:
#Modifying
#Query(nativeQuery = true, value= "update tequipment set equipment_status = (CASE WHEN (...))")
void updateEquipmentStatus(#Param("id_param") Long idEquipment);
UPDATE2
Having done more tests and added a log with TransactionSynchronizationManager.getCurrentTransactionName() in the methods, that's the concrete issue:
Changes done in the equipment service are properly picked by the updating function (When something in tequipment changes, the status in tequipment is calculated properly).
Changes done in the revision service (trevision) result in an outdated value in tequipment (it doesn't matter if Spring does it in a different transaction using REQUIRES_NEW or not). Spring seems to create a new transaction properly when using REQUIRES_NEW in establishEquipmentStatus, because the current transaction name changes, but the native query doesn't have the latest values (because of the transaction before not being commited?). Also tried removing #Transactional from establishEquipmentStatus so the same transaction is used, but the issue keeps happening.
I would like to highlight that the query used to update equipment status has a case expression with multiple subqueries using trevision.
Adding the following code fixes it (programatically flushing the transaction state to the Database):
#Service
public class EquipmentService{
#PersistenceContext
private EntityManager entityManager;
#org.springframework.transaction.annotation.Transactional
public Long updateEquipmentStatus(Long idEquipment){
entityManager.flush();
repo.updateEquipmentStatus(idEquipment);
}
}
Still it would be great to find a declarative way to do it..
Changing to read uncommitted is the right idea but you'd also need to flush the entitymanager before your stored procedure is called. See this thread:
How to make the queries in a stored procedure aware of the Spring Transaction?
Personally I'd do it all in Spring unless you are absolutely forced to use a stored procedure.
Related
I am writing an springboot component which is simply responsible for auditing login operation.
Since component is only responsible to write into database and there will be no retrieve(select) operation on table. I am simply using #Repository(org.springframework.data.repository.Repository) package and implemented method with insert into statement to write in database.
#Repository
public interface AuditRepository extends Repository<UserAudit,String> {
#Modifying
#Query(value = "insert into user_audit(user_id,datetime,function_code,ip_address) values (:user_id,:datetime,:function_code,:ip_address)",nativeQuery = true)
#Transactional
public void recordUserAudit(#Param("user_id")String user_id, #Param("datetime") Timestamp datetime, #Param("function_code") int function_code, #Param("ip_address") String ipAddress);
}
Execution of this method on http request does works out.
I'd want to write junit tests on H2 database which verifies record is inserted correctly. for which I am using test profile. inserting record on test method with H2 dependency also seem to work - however I currently don't see a way to verify existence of record.
Any suggestions How to achieve it?
Ps. I understand this is possible with either #JpaRepository(org.springframework.data.jpa.repository.JpaRepository) or #CrudRepository but I'd prefer not to use them as using Repository and distinct method will make application light weight.
you can #Mock your #Repository object and with org.mockito.Mockito.verify and will be able to verify if the Sql written above does gets executed upon calling. (authentication request)
ie. mock AuditRepository and verify object.
verify(auditRepository).recordUserAudit(user_id,datetime, function_code, ipAddress);
I have implemented EntityListener in eclipseLink. My app is built using spring-boot , spring-data and eclipseLink. I have a requirement of inserting record in 2 table (Audit tables) when data in inserted in 1 table. I have got EntityManager in my Listener and everything seems to works normally. When I debug the code I can see that entities which I am going to save are having "id" generated from the sequence which is maintained at DB level. BUT when the transaction is committed I see only main table data but audit tables data is not getting committed. Here is the sample code :
#Entity
#Table(name="MyTable")
#EntityListeners(MyTableListener.class)
public class MyTable implements Serializable{
private static final long serialVersionUID = -5087505622449571373L;
private Long id;
// Rest of the fields
#Id
#GeneratedValue(strategy=GenerationType.SEQUENCE, generator="MASTER_SEQ")
#SequenceGenerator(name="MASTER_SEQ",sequenceName="MASTER_SEQ",allocationSize=1)
public Long getId() {
return id;
}
// Getters/Setters
}
Listener code :
public class MyTableListener extends DescriptorEventAdapter {
#Override
public void postInsert(DescriptorEvent event) {
MyTable msg = (MyTable)((InsertObjectQuery) event.getQuery()).getObject();
EntityManager em = BeanUtil.getBean(EntityManager.class);
MyAudit statusAudit = new MyAudit();
statusAudit.setNewVal("NEW");
statusAudit.setOldval(null);
statusAudit.setTargetColumnName(targetColumn);
statusAudit.setTargetRecordId(msg.getId());
em.persist(statusAudit);
}
}
Nothing seems to be wrong with the code. BUT when I see in the set the sql logs to "FINEST" , I can see that insert queries are not being fired for audit tables.
I have been dealing with this problem for more than 2 days and dont understand what exactly is wrong. Please help me.
You are never calling flush on the EntityManager. I suspect something like the following is going on:
You add your domain entities to the EntityManager, possibly through Spring Repositories.
Something triggers a flush, possibly the transaction handling of Spring.
Your domain entities get flushed.
Your event listener gets triggered.
You add audit entities to the EntityManager, but those never get flushed.
The database connection gets a commit. Saving everything but your audit trail.
If this theory ist correct, which you should be able to verify through the logs and debugger, you can probably fix it, by adding a call to flush in your listener.
As you described in the comments this causes further problems, which happen because you are trying to do something which you are not supposed to be doing.
According to this article, the JPA spec does not allow usage of the entitymanager inside callback events.
In general, the lifecycle method of a portable application should not invoke EntityManager or Query operations, access other entity instances, or modify relationships within the same persistence context. A lifecycle callback method may modify the non-relationship state of the entity on which it is invoked.
So looks, like we are stuck here, so you probably should consider a completely different approach like EclipseLink History tables.
I have an entity "Job" with a boolean flag "suspended":
#Entity
#XmlRootElement(name = "Job")
#Where(clause = "deleted=0")
public class Job {
...
#Id
#GeneratedValue(strategy = GenerationType.AUTO)
private int id;
private boolean suspended;
...
}
And a Spring CrudRepository (JPA Hibernate) is used for persistence:
#Repository
public interface JobRepository extends CrudRepository<Job, Integer>, JobStatusSupport {}
I need to update the "suspended" flag individually, without overwriting updates done to other fields in concurrent threads. So the natural thing to do seemed to be writing a method that only updates the "suspended" field:
public class JobRepositoryImpl implements JobStatusSupport {
private final static String SET_SUSPENDED = "UPDATE Job SET suspended = :suspended, modificationDate = :modificationDate WHERE id = :id";
#Override
public int setSuspended(int id, boolean suspended, Instant modificationDate) {
int updateCount = em.createQuery(SET_SUSPENDED)
.setParameter("suspended", suspended)
.setParameter("modificationDate", modificationDate)
.setParameter("id", id)
.executeUpdate();
return updateCount;
}
}
Now I have the following scenario in my code (shortened obviously, in reality this is spread out over several methods, but this example does reproduce the problem):
#Transactional
public void resumeJob(int id) {
Job jobA = jobRepository.findOne(Integer.valueOf(id));
// jobA.suspended == true
// let's set "suspended" to "false"
int updateCount = jobRepository.setSuspended(id, false, Instant.now());
// OK: updateCount is 1
Job jobB = jobRepository.findOne(Integer.valueOf(id));
// jobB.suspended == true ??? that was just set to "false, wasn't it?
}
Probably I am missing some basics about JPA/Hibernate. But still, this is extremely counterintuitive: Why is jobB.suspended still "true" although the update is successful and the data is read again "from the DB"? Why is the update of the individual field not visible within the transaction?
(As one would expect, after the transaction is complete, Job.suspended is "false" in the database and for subsequent reads.)
How would one go about this properly? How should I write code that updates individual fields so that JPA becomes aware of what was done? Do I have to look into "merge" for something as simple as this?
Being able to write our own SQL statements is crucial for our project. I am trying Spring Data JPA mainly to avoid the tedious work of writing tons of CRUD operations. But if I am already encountering such problems with this simple scenario, I am wondering whether we would not be better of using JdbcTemplate.
UPDATE: LEARNED SOMETHING ABOUT ORM
Man, was I clueless! I worked in projects where JPA was used before. But I never had to deal with it in detail (and I wonder if anybody else did).
The entire effort of writing an "update method" is futile! I have reduced this to the following:
#Transactional
public void resumeJob(int id) {
Job job = jobRepository.findOne(Integer.valueOf(id));
job.setSuspended(false);
job.setName("And Now for Something Completely Different.");
}
That's all! This updates the DB and the cache and God knows what. The #Transactional annotation alone is sufficient for persisting the changes. If the annotation is removed, the DB remains unchanged. So ORM is basically working against a cache (through "attached objects") that everybody sees. Then one hopes that people put #Transactional in the right places (not on private methods, for example...) and that the ORM machinery knows what it is doing (for example, not making cache updates visible outside of an open transaction).
Honestly, this seems a bit too magic for my taste. But now that I know what it is all about, I will give it a try. Writing gazillions of CRUD methods isn't very appealing, either.
Please comment if I got this wrong or if you have links with best practices. (I am starting to wonder if it wouldn't be best to immediately detach every object I get from the DB, defeating the entire purpose of ORM :-)
UPDATE: EntityManager#clear() Is Enough for a Quick Fix
This is definitely not the clever way to use ORM, but for the moment I can simply call clear() in the few update methods I have written. This invalidates the entire cache and the next read somewhere else in the transaction receives the updated data. Of course, the right way to do it, would be to simply modify the attached entity, i.e. "job.setSuspended(false);".
Calling flush() is not needed, probably it only becomes of interest when you want to minimize the risk of losing data in case of a system crash. I suppose that Hibernate does not immediately write completed transactions to disk?
It's counter-intuitive, but if you think about it, it's quite normal.
You load an entity with ID 3. Hibernate stores it in its session cache
You execute an update query. This query is almost a black box to Hibernate. It can't know which rows are affected by the changes, and you're not doing these changes by modifying the entities, but by modifying rows in the database directly. So the rows are modified, but the entity with ID 3 is left, untouched, in the session cache
You load the entity again, in the same session. So Hibernate just returns the instance that is already in the cache, and thus doesn't contain the changes.
If you want an updated entity, you have two solutions:
modify the database by modifying the entity, or
clear the cache after the update query has been made.
I am using JPA with Spring and saving an entity in a test. In the process of writing a test to validate that an entity's relationship with another entity is correctly set up, I have come across a problem that I come across frequently. I have a test method (set to rollback) that:
Creates entity
Saves entity
Flushes
Retrieves entity
Validates entity
The problem is that when I look at the Hibernate logs, I only see a single insert to the database where I'd expect to see an insert and then a select.
I know this is because Hibernate's trying to save me some time and knows that it's got the entity with the ID I'm trying to retrieve but that bypasses an important step: I want to make sure that the entity actually made it to the database and looks like what I thought it should. What's the best way to deal with this so I can test that the entity is actually in the database?
Note: I assume this involves somehow detaching the entity or telling Hibernate to clear its cache but I'm not sure how to do that when all I have access to is a JpaRepository object.
Some code:
public interface UserRepository extends JpaRepository<User, Long> {
//...
}
#RunWith(SpringJUnit4ClassRunner.class)
#ContextConfiguration(classes = JpaConfig.class, // JpaConfig just loads our config stuff
loader = AnnotationConfigContextLoader.class)
#TransactionConfiguration(defaultRollback = true)
public class UserRepositoryTest {
#Test
#Transactional
public void testRoles() {
User user = new User("name", "email#email.com");
// eventually more here to test entity-to-entity relationship
User savedUser = userRepository.save(user);
userRepository.flush();
savedUser = userRepository.findOne(savedUser.getId());
Assert.assertNotNull(savedUser);
// more validation here
}
}
You basically want to test Hibernate's functionality instead of your own code. My first suggestion: don't do it! It is already tested and validated many times.
If you really want to test it, there are a couple of options:
Execute a query (rather than a get. The query will get executed (you should see it in the log) and the result interpreted. The object you get back would still be the same object you saved, since that is in the session.
You can evict the object from the session and then get it again. If you use SessionFactory.getCurrentSession(), you'll get the same season that the repository is using. With that you can evict the object.
You have two strategies:
issue a native SQL query therefor bypassing any JPA cache.
ensure the persistence context is cleared before reloading.
For (1) you can change your tests to extend the following Spring class which, in addition to automatically beginning/rolling back a transaction at the start/end of each test, will give you access to a Spring JdbcTemplate you can use to issue the native SQL.
http://docs.spring.io/spring-framework/docs/2.5.6/api/org/springframework/test/context/junit4/AbstractTransactionalJUnit4SpringContextTests.html
http://docs.spring.io/spring-framework/docs/2.5.6/api/org/springframework/jdbc/core/simple/SimpleJdbcTemplate.html
For (2) you can clear the persistence context by doing the following (where the EntityManagerFactory is injected into your test:
EntityManagerFactoryUtils.getTransactionalEntityManager(entityManagerFactory).clear();
See the following base test class which I normally use and demonstrates the above and also allows for populating the database with known data before each test (via DBUnit).
https://github.com/alanhay/spring-data-jpa-bootstrap/blob/master/src/test/java/uk/co/certait/spring/data/repository/AbstractBaseDatabaseTest.java
(In fact in the above I am actually creating a new JdbcTemplate by injecting a datasource. Can't remember why...)
I have the following method:
#Transactional
public void onEmailMessage() {
this.departmentService.removeUserFromDepartments(user, depsids);
this.departmentService.getDepartmentUsers(user.id);
}
The weird thing when i invoke this method, the first line:
this.departmentService.removeUserFromDepartments(user, depsids);
is called but the DB is not changing at all and the user is still connected to the deparment (many to many relation)
afterwards the method :
this.departmentService.getDepartmentUsers(user.id);
is called and returns users that are connected to the department including the removed user from line#1.
when the method returns - if i check the DB the user i removed is actually been removed from the table!
can i make the query return the actual updated values??
There is nothing weird about this. You are performing two different queries within the same transaction. Persistence context is updated, but the transaction hasn't been committed yet, and you can't see your changes after first line is finished. Transaction is a set of statements (in this case - statements created by those two methods of yours) which gets executed after commit is invoked. When the whole (onEmailMessage) method finished it's job, the transaction is committed and you are seeing the changes.
The solutions would be:
Make them as two separate transactions. For e.g:
#Transactional
public void removeUser(...) {
someInstance.departmentService.removeUserFromDepartments(user, depsids);
}
And:
#Transactional
public List<?> getUsers(...) {
return someInstance.departmentService.getDepartmentUsers(user.id);
}
Then the highest level would be onEmailMessage() method, which has to be non-transactional and in separate class then these two methods above. Call them both in this level and it will work.
You have marked it as Transactional. Changes in DB is made after executing all the queries. Either all of the operations will be committed or none.
The transaction hasn't been committed yet so changes won't necessarily have been written to the DB.
You could try calling
entityManager.flush();
after removeUserFromDepartments() but before getDepartmentUsers() to force the DB changes to be written before the commit.