How to RollBack a transaction of an EntityManager injected by #PersistenceContext? - java

I am using JPA and i have an abstract class where i inject my entityManager and i have a generic method where i persist my oject to the database and in all my services class extends that abstract class but the issue is: sometimes i have to persist client and client details but if i have an exception in the persist of client , then my program persist client details that's why i look for a rollBack to call when i have a persist exception.
I khow that i can do like entityManager.getTransaction().rollback(); but if i manage my entity manager but in my case , it managed by the container.
Here is my abstract class:
public abstract class AbstractEntityFactory<E>{
protected static final transient Logger LOGGER = CommonLogger.getLogger(AbstractEntityFactory.class);
#PersistenceContext(unitName = "Test_PU")
#Transient
#XmlTransient
private transient EntityManager entityManager;
public E persist(final E arg0) {
LOGGER.debug("persist : Begin");
this.getEntityManager().persist(arg0);
this.getEntityManager().flush();
LOGGER.debug("persist : End");
return arg0;
}
}
NB: i have Jboss EAP6 as server

You can try using UserTransaction.rollback to roll back the current transaction.

Since your using a "container". I assume you mean something like wildfly,..
In that case I assume your using #Transactional somewhere. This annotation has an attribute called rollbackFor.
If I remember correctly the default setup does not rollback for RuntimeExceptions. So you might wana change this.
If you need to rollback manually use the UserTransaction. You should be able to get it via
public class SomeBean {
#Resource
private UserTransaction transaction;
}

you can use transaction rollback support annotation :
` #Transactional(propagation=Propagation.REQUIRED, rollbackFor=Exception.class)
public E persist(final E arg0) {
LOGGER.debug("persist : Begin");
this.getEntityManager().persist(arg0);
this.getEntityManager().flush();
LOGGER.debug("persist : End");
return arg0;
}`

Related

For spring-batch transaction is not getting rolled back after exception

I am working on a spring-batch, where after reader and processor, writer is responsible to populate data to DB. Writer is calling Service which internally calls DAO layer. In method insertToDB() if some exception occurs the transaction is not being rolled back. PSB my code.
public class MyWriter{
#Autowired
private MyService myService;
#Override
public void write(List<? extends MyBO> list) {
try{
for(MyBO bo: list){
myService.insert(bo);
}
}
catch(Exception e){
log.error("Cant write to DB")
}
}
public class MyService{
#Autowired
private TableOneDAO tableOneDao;
#Autowired
private TableTwoDAO tableTwoDAO;
#Autowired
private TableThreeDAO tableThreeDAO;
public void insert(MyBO bo){
try{
// do other stuff of processing bo and create entity
MyEntityTableOne myentity1 = getEntityT1(bo);
MyEntityTableTwo myentity2 = getEntityT2(bo);
MyEntityTableThree myentity3 = getEntityT3(bo);
insertToDB(myEntity1,myEntity2,myEntity3);
}
catch(Exception e){
log.error("Error occured.");
throw new MyException("Error Blah blah occured");
}
}
#Transactional(value = "txn1")
public void insertToDB(MyEntityTableOne entity1, MyEntityTableTwo entity2, MyEntityTableThree entity3) {
try{
tableOneDao.insert(entity1);
tableTwoDAO.insert(entity2);
tableThreeDAO.insert(entity3);
}
catch(Exception e){
log.error("Error occured during insert to DB");
throw new MyException("Error Blah blah occured during DB insert");
}
}
The code goes to the catch block, but doesn't rollback records. If some error occurs during insert of Table2 then entry for Table1 is not rolled-back. And if occurs during table3 insertion then table1 and table2 records are not rolled-back.
If I move the #Transactional annotation to insert() method it works fine. What is root cause of this issue. What I have to do if I want to have transaction only on insertToDB() method.
I am trying to make it simple: To support #Transactional spring wraps the implementing class into a so called proxy and surrounds the method call / class with the transactional logic.
Now you are calling the #Transactional annotated method within the same class. Therefore the proxy is not invoked and the transactional does not work. When moving the annotation to your insert method you are invoking the method from outside of the class which means you invoke the method against the proxy.
Thats a limitation of Spring AOP (?) I think.
You can do something like following to achieve what you want:
public class MyService{
#Ressource
private MyService self;
...
self.insertToDB(myEntity1,myEntity2,myEntity3)
Your item writer will be already called in a transaction driven by Spring Batch and that you can configure at the step level by providing the transaction manager and transaction attributes. So there is no need to use #Transactional in the downstream service used by the writer.
You need to remove that annotation from MyService and it should work as expected.

JSON mapping problem: possible non-threadsafe access to the session

I am facing a problem due which is unknown to me, can you one have faced this problem?
JSON mapping problem: <package>ApiResponse["data"]; nested exception is com.fasterxml.jackson.databind.JsonMappingException: possible non-threadsafe access to the session (through reference chain: <package>.ApiResponse["data"])
I have a standard API response pojo. Which I return every time with ResponseEntity. Everything is working fine, but sometimes I got that above error. I don't why this error occurred .
I got the below log from console
an assertion failure occurred (this may indicate a bug in Hibernate, but is more likely due to unsafe use of the session): org.hibernate.AssertionFailure: possible non-threadsafe access to the session
org.hibernate.AssertionFailure: possible non-threadsafe access to the session
I think you are trying to share same Hibernate session within multiple threads. That's illegal.
Hibernate Sessions are not thread-safe whereas Hibernate SessionFactory is thread-safe.
So, make a separate DAO layer. Create single sessionfactory object and share it among the DAO classes.
Get a session for a single-threaded DB operation and close the session in that thread.
For example :
#Repository
public class DAO {
#Autowired
private SessionFactory sessionFactory;
public class performDBOperation(Object obj) {
Session session = sessionFactory.currentSession();
session.save(obj);
session.close();
}
}
Now, I have looked at your github code.
I saw the code Exec.java
#Service
public interface Exec {
#Async
#Transactional
public void run();
}
This is incorrect.
Updated :
public interface Exec {
public void run();
}
Update ExecImpl to this :
#Service
public class ExecImpl implements Exec {
#Autowired
private ExecDAO execDAO;
#Override
#Async
#Transactional
public void run() {
// example : create an object to save it.
Object object = ...;
execDAO.saveItem(object);
}
}
Create DAO layer :
Suppose ExecDAO interface and implementation ExecDAOImpl :
public interface ExecDAO {
public void saveItem(Object obj);
// keep here abstract method to perform DB operation
}
#Repository
public class ExecDAOImpl implements ExecDAO {
#Autowired
private SessionFactory sessionFactory;
#Override
public void saveItem(Object obj) {
Session session = sessionFactory.currentSession();
session.save(obj);
session.close();
}
}
Looking at the code at the link you shared in the comment, I think that
#Async
#Transactional
is a dangerous thing.
I would suggest you to extract a method to do the transactions and try
what I mean is that,
interface ExecImpl{
#Async
void run(){
someThingElse.doTransaction();
}
}
interface SomeThingElse{
#Transactional
void doTransaction();
}
I am still not convinced this will help you. But this is something you can try.
I would also suggest to use readonly transactions for getting data and not have a single transaction for all purposes.
This blog explains why its not good to use these two annotations together whether on a class or on an interface

Hibernate domain object 'not null' field - mock test should throw error if field is null within object

There is an Hibernate domain object that have 'not null' field which have annotation #Column(nullable=false), a DAO class method which is saving this object in DB.
I am mocking the create DAO call using PowerMockito, mock call is working fine but if i am passing null for the field, mock test is not throwing error that field is null.
Below is the code, tools/techs (java, spring, hibernate, sqlserver, junits, powermockit). Few code changes omitted related to spring context and hibernate session configurations.
public class Entity{
private String id;
#Column(nullable=false)
private String field;
//setters and getters goes here
}
public class HibernateDAO{
private SessionFactory sessionFactory;
public void create(Entity entity){
getSession().save(entity);
}
public void setSessionFactory(SessionFactory sf){
sessionFactory = sf;
}
}
public class HibernateDAOTest{
HibernateDAO hibernateDAO = new HibernateDAO();
public SessionFactory mockedSessionFactory;
public Session mockedSession;
public Query query;
public SQLQuery sqlQuery;
public Transaction mockedTransaction;
#Before
public void setup() {
mockedSessionFactory = PowerMockito.mock(SessionFactory.class);
mockedSession = PowerMockito.mock(Session.class);
mockedTransaction = PowerMockito.mock(Transaction.class);
query = PowerMockito.mock(Query.class);
sqlQuery = PowerMockito.mock(SQLQuery.class);
PowerMockito.when(mockedSessionFactory.openSession()).thenReturn(mockedSession);
PowerMockito.when(mockedSessionFactory.getCurrentSession()).thenReturn(mockedSession);
PowerMockito.when(mockedSession.beginTransaction()).thenReturn(mockedTransaction);
}
#Test
public void testCreate(){
Entity entityToSave = new Entity();
entityToSave.setId("123");
entityToSave.setField(null);
hibernateDAO.setSessionFactory(mockedSessionFactory);
hibernateDAO.create(entityToSave);//this call should throw error that "field" is null but its not.
}
}
Actually the validation (not-nullability check) is not done in your DAO. You do declare your field as not-null, but then your create(Entity entity) method calls:
getSession().save(entity);
and that is all it does. Now the validation would happen within the saving via HibernateSession, but all those classed are mocked. So they will not perform any validation.
Generally it is a good rule, that each time you accidentally mock the very same thing you tested, you step back and re-evaluate:
Did I write that code? Why do I want to test it?
In this case probably the answer is, that you should trust Hibernate taking care of things. And if you want to test your model definition, you need to setup a full Hibernate context and perform a real test with Hibernate not being mocked.

Smaller stacktrace: database exceptions

simple example, i have a user with a unique name in the database. Now i add a user with same name as an existing user. I get a very big exception- stacktrace for it. Can i reduce this output with a parameter from openjpa? I tried some of this, but nothing works: http://openjpa.apache.org/builds/1.0.1/apache-openjpa-1.0.1/docs/manual/ref_guide_logging.html
The other solution is to check the name before persisting, but i think thats an overhead or?
#ViewScoped
#ManagedBean
public class MyBean {
#EJB
private MyStateless stateless;
public void save(ActionEvent event){
try{
stateless.save();
}catch(Exception e){
System.out.println("####EXCEPTIOn");
}
}
}
#Stateless
#LocalBean
public class MyStateless{
#PersistenceContext(unitName = "pu")
private EntityManager em;
public void save() {
Person p = new Person(1, "Name");
em.persist(p);
}
}
org.apache.openjpa.persistence.EntityExistsException: The transaction has been rolled back. See the nested exceptions for details on the errors that occurred.
FailedObject: myejb.Person#1100245.......
2014-03-02T10:43:47.969+0100|Information: ####EXCEPTIOn
Here i get the javax.ejb.EJBException with the wrapped EntityExistsException

Java Spring #Transactional method not rolling back as expected

Below is a quick outline of what I'm trying to do. I want to push a record to two different tables in the database from one method call. If anything fails, I want everything to roll back. So if insertIntoB fails, I want anything that would be committed in insertIntoA to be rolled back.
public class Service {
MyDAO dao;
public void insertRecords(List<Record> records){
for (Record record : records){
insertIntoAAndB(record);
}
}
#Transactional (rollbackFor = Exception.class, propagation = Propagation.REQUIRES_NEW)
public void insertIntoAAndB(Record record){
insertIntoA(record);
insertIntoB(record);
}
#Transactional(propagation = Propagation.REQUIRED)
public void insertIntoA(Record record){
dao.insertIntoA(record);
}
#Transactional(propagation = Propagation.REQUIRED)
public void insertIntoB(Record record){
dao.insertIntoB(record);
}
public void setMyDAO(final MyDAO dao) {
this.dao = dao;
}
}
Where MyDAO dao is an interface that is mapped to the database using mybatis and is set using Spring injections.
Right now if insertIntoB fails, everything from insertIntoA still gets pushed to the database. How can I correct this behavior?
EDIT:
I modified the class to give a more accurate description of what I'm trying to achieve. If I run insertIntoAAndB directly, the roll back works if there are any issues, but if I call insertIntoAAndB from insertRecords, the roll back doesn't work if any issues arise.
I found the solution!
Apparently Spring can't intercept internal method calls to transactional methods. So I took out the method calling the transactional method, and put it into a separate class, and the rollback works just fine. Below is a rough example of the fix.
public class Foo {
public void insertRecords(List<Record> records){
Service myService = new Service();
for (Record record : records){
myService.insertIntoAAndB(record);
}
}
}
public class Service {
MyDAO dao;
#Transactional (rollbackFor = Exception.class, propagation = Propagation.REQUIRES_NEW)
public void insertIntoAAndB(Record record){
insertIntoA(record);
insertIntoB(record);
}
#Transactional(propagation = Propagation.REQUIRED)
public void insertIntoA(Record record){
dao.insertIntoA(record);
}
#Transactional(propagation = Propagation.REQUIRED)
public void insertIntoB(Record record){
dao.insertIntoB(record);
}
public void setMyDAO(final MyDAO dao) {
this.dao = dao;
}
}
I think the behavior you encounter is dependent on what ORM / persistence provider and database you're using. I tested your case using hibernate & mysql and all my transactions rolled back alright.
If you do use hibernate enable SQL and transaction logging to see what it's doing:
log4j.logger.org.hibernate.SQL=DEBUG
log4j.logger.org.hibernate.transaction=DEBUG
// for hibernate 4.2.2
// log4j.logger.org.hibernate.engine.transaction=DEBUG
If you're on plain jdbc (using spring JdbcTemplate), you can also debug SQL & transaction on Spring level
log4j.logger.org.springframework.jdbc.core=DEBUG
log4j.logger.org.springframework.transaction=DEBUG
Double check your autocommit settings and database specific peciular (eg: most DDL will be comitted right away, you won't be able to roll it back although spring/hibernate did so)
Just because jdk parses aop annotation not only with the method, also parse annotation with the target class.
For example, you have method A with #transactional, and method B which calls method A but without #transactional, When you invoke the method B with reflection, Spring AOP will check the B method with the target class has any annotations.
So if your calling method in this class is not with the #transactional, it will not parse any other method in this method.
At last, show you the source code:
org.springframework.aop.framework.jdkDynamicAopProxy.class
public Object invoke(Object proxy, Method method, Object[] args) throws Throwable {
......
// Get the interception chain for this method.
List<Object> chain = this.advised.getInterceptorsAndDynamicInterceptionAdvice(method, targetClass);
// Check whether we have any advice. If we don't, we can fallback on direct
// reflective invocation of the target, and avoid creating a MethodInvocation.
if (chain.isEmpty()) {
// We can skip creating a MethodInvocation: just invoke the target directly
// Note that the final invoker must be an InvokerInterceptor so we know it does
// nothing but a reflective operation on the target, and no hot swapping orfancy proxying.
retVal = AopUtils.invokeJoinpointUsingReflection(target, method, args);
}
else {
// We need to create a method invocation...
invocation = new ReflectiveMethodInvocation(proxy, target, method, args, targetClass, chain);
// Proceed to the joinpoint through the interceptor chain.
retVal = invocation.proceed();
}
}

Categories