I am using spring Transactional annotation which is overriding custom exception:
Application exception overriden by commit exception
lets say
#Transactional
method A() {
try {
} catch (MyException e) {
throw MyException(e.getMessage, e);
}
}
Now exception I got from code which is calling A is transaction rollback exception.
I want exact exception thrown by code, but Apache ExceptionUtils.getRootCause is returning transaction rollback messages which doesn't clarify anything.
How can I propagate exact application exception to caller method in this case?
Related
I know that unchecked Exceptions (RuntimeExceptions) will usually cause a rollack of your transaction but what happens if you catch that exception in the same mothod? I want the rollback the whole transaction when errorOccurred is true. But I wonder if catching Exception will swallow the RuntimeException hence causing the transaction to NOT rollback? Does this code still rollback the transaction?
public static void main(String[] args) {
try {
// boring stuff...
if(errorOccurred)
throw new RuntimeException("RuntimeException is thrown.");
} catch (Exception e) {
System.out.println("RuntimeException cought. Does is still rollback transaction?");
}
}
If your program catches the run time exception that means exception has not reached to JEE container, hence from JEE container perspective it is normal program execution, so it will not rollback transaction.
If you want to catch the runtime exception as well as rollback the transaction you need to programmatically rollback the transaction on those specific runtime exception. In session bean it provides sessioncontext object which has method setRollbackOnly , with this method you can inform the container to rollback transaction without throwing runtime exception. Message driven bean also provides messagedrivencontext object which can be used to rollack transaction[ check for MDB https://docs.oracle.com/javaee/6/tutorial/doc/bnbpo.html]
I have method in my service class.
#Transactional
public void serviceMethod {
dao.daoMethod();
}
public void daoMethod() {//dao.daoMethod
//some code
try {
//some more code that throws an unchecked exception
} catch(Exception exception) {
//do something -- no exceptions generated/thrown from here
}
//some more code
}
Will this result in the transaction rolling back?
If the Unchecked exception was thrown from within a method that was called from the try block would it be any different?
No, the transaction will only be rolled back in case of an uncaught exception.
The transactional interceptors "wrap" around the calls of the annotated methods; they cannot see what happens inside them.
In your case it will silently ignore the exception. You didn't do anything inside the catch block. This is not advised at all.
If you catch an Exception in the try-catch block and you did some actions to handle this Exception - a rollback will not happen. In the case with RuntimeException, by default - the rollback will occur.
You can specify, which exceptions should cause the rollback. #Transactional(rollbackFor = MyCheckedException.class)
https://resourcepool.io/2014/11/16/java-quickies-what-you-wish-you-knew-about-spring-transactional-annotation/
https://www.catalysts.cc/wissenswertes/spring-transactional-rollback-on-checked-exceptions/
I have a set of operation i would like to be rollbacked if there are an error.
My class
public class BSException extends RuntimeException{
...
}
public class saleFacade{
public update(){
for (){
try{
renewSale();
}
catch(BSException){
logger.error();
}
}
}
#Transactional
public renewSale(){
try{
findSale(); // read only Transactional
xxx.renewSpecialSale();
}
catch(Exception e){
logger.error(...);
}
}
}
public class xxx(){
public void renewSpecialSale(){
payFee(); //write to db
if(error){
throw new BSException();
}
}
#Transactional(propagation = Propagation.REQUIRED)
public payFee(){
try{
...
}
catch(BsException e){
...
}
catch(Exception e){
...
}
}
}
#Configuration
#EnableTransactionManagement
public class DBConfiguration{
#Bean(name = "dataSource")
public BasicDataSource dataSource(){
...
}
}
Inn renewSpecialSale error is throw.
In the renewSale method, if there is an error, i would like to rollback.
Right now nothing is rollbacked
any idea?
If you catch the exception before it leaves the method, then there is no way the proxy wrapping the method can know that an exception was thrown.
Either remove the try-catch entirely or rethrow the exception so that the exception can leave the method that you marked #Transactional (and get intercepted by the proxy), and the rollback will take place.
I recommend removing exception-handling from all these methods. Set up a central exception handler so that anything thrown from the controllers gets caught and logged, and otherwise let exceptions get thrown.
Make sure each of these classes that does something transactional is annotated separately, if you annotate on the method-level then each method that does something transactional should be annotated. Calling a transactional method from a non-transactional method on the same object doesn't go through the proxy (the proxy intercepts only those calls coming in from outside the object, and only then if that method is marked as transactional) so it isn't part of a transaction (+1 to Peter's answer for pointing this out).
I have no idea what your error flag is doing, it seems odd. Spring services shouldn't have state. If you fix the exception-handling you shouldn't need error flags.
The problem comes from your nesting of Method calls and the usage of #Transactional. By default Springs Transaction Management
In proxy mode (which is the default), only external method calls coming in through the proxy are intercepted. This means that self-invocation, in effect, a method within the target object calling another method of the target object, will not lead to an actual transaction at runtime even if the invoked method is marked with #Transactional. Spring Transaction Management
This means, that the call of
xxx.payFee()
is not surrounded by a transaction when it's called through
saleFacade.update() -> saleFacade.renewSale() -> xxx.renewSpecialSale()
As far as I got it, you have at least these options
Mark xxx.renewSpecialSale() as #Transactional
Mark saleFacade.update() as #Transactional
Mark both classes xxx and saleFacade #Transactional
Also you can create your own custom exception class and throw it.
Just throw any RuntimeException from a method marked as #Transactional.
By default all RuntimeExceptions rollback transaction whereas checked exceptions don't. This is an EJB legacy. You can configure this by using rollbackFor() and noRollbackFor() annotation parameters:
#Transactional(rollbackFor=Exception.class)
This will rollback transaction after throwing any exception.
#Transactional(rollbackFor = MyCheckedException.class)
public void foo() {
throw new RuntimeException();
}
remove try catch block from your method and put below line of code
#Transactional(propagation = Propagation.REQUIRED, rollbackFor = Exception.class)
use this line of code insted of
#Transactional(propagation = Propagation.REQUIRED)
In above code spring container handle whole transaction management and here if we provide rollback attribute it automatically manage if any kind of exception occur it will rollback your transaction
and make sure that you have entry of transaction in your configuration file as below
<tx:annotation-driven />
and also
I hope it will sure help you
I call account EJB method in JSF bean like that :
try{
account.someFunction(...);
}catch(SimRuntimeException e){
logger.log(Level.FATAL, "SimRuntimeException catched !");
}catch(SimNotRuntimeException e){
logger.log(Level.FATAL, "SimNotRuntimeException catched !");
}catch(Exception e){
logger.log(Level.FATAL, "Exception catched !");
}
My Exceptions :
public class SimRuntimeException extends RuntimeException {
public SimRuntimeException() {
super();
}
}
#ApplicationException(rollback=true)
public class SimNotRuntimeException extends Exception {
public SimNotRuntimeException() {
super();
}
}
when account.someFunction(...); throws SimRuntimeException I fall
into Exception block because my SimRuntimeException is wrapped
into EJBException probably by EJB container.
when account.someFunction(...); throws SimNotRuntimeException I fall as expected
into SimNotRuntimeException
So, what is concretely the difference between Exception with #ApplicationException(rollback=true) and RuntimeException please ?
Pal's blog states:
EJB makes a difference in Application Exceptions and System Exceptions. Application exception is something that you define, you throw, and you are aware of. By default the application exception does not cause a rollback, unless you define it that way (and I think it's recommended). Every checked exception that is mentioned in the method signature and also any checked or unchecked exception that is annotated with #ApplicationException, is an application exception.
System exceptions happen in cases, you don't control, and they are unchecked exceptions. They always cause rollback. Good practice is, if you wrap checked exceptions -- that cannot be avoided -- in your method into EJBException e.g. ParseException.
I am using EJB3 on Glassfish using the default TopLink persistance manager. Within a Session Bean, when the persistence manager catches a DB exception, it marks the transaction to be rolled back, and throws an EJBException, in turn wrapping a RollbackException. Now I was expecting to be able to get the original jdbc exception out of the caused by exception of one of these exceptions, but it is not.
It is important that I do retrieve the original exception, as I need to report back to the users what the problem is, and to do this I need to analyse the SQL error codes.
Does anyone know if it is possible to get this information from Toplink? Or whether Hibernate makes it possible?
Thanks,
I had the same issue. I ended up using the AroundInvoke interceptor method , that way you can catch any exception on the server side , and extract whatever info you want to and wrap it to throw your own exception , and set the EjbContext to rollback the transaction.
I can provide you with an example if you don't come right.
Good question, Ant
I know you want to throw a database exception but when it occurs the application, in most of the time, is not able to restore its initial state or it does not know how to recover from it. So it should be handled as a runtime exception. Some problems in database exceptions includes
database connection failure
query is wrong
table or column does not exist
Above you see the application is not be able to restore its initial state. If you think it is possible restore its initial state so you should use a application exception. Client will get the same application exception thrown by your business method. If you want to be able to get the exact exception thrown by your business method you have two choices:
Use a business delegate pattern to access your EJB
As you know, runtime exception is wrapped by a EJBException, so you shold use something like
Let's suppose you have this Stateless session bean
#Stateless
public class BeanImpl implements Bean {
public void doSomething() {
try {
// some code
} catch(SomeException e) {
throw new EJBException(e);
}
}
}
So you wrap your session bean through a business delegate
public class BeamBusinessDelegate implements Bean {
// your stateless session bean goes here
private Bean bean;
public BeamImpl() {
InitialContext i = new InitialContext();
bean = (Bean) i.lookup(<GLOBAL_JNDI_ADDRESS_OR_RELATIVE_ENVIRONMENT_NAMING_CONTEXT_ADDRESS>);
}
public void doSomething() {
try {
bean.doSomething()
} catch(EJBException e) {
throw e.getCause();
}
}
}
Or you can extends EJBException according to your needs
public class DatabaseException extends EJBException {
}
So in your business method
#Stateless
public class BeanImpl implements Bean {
public void doSomething() {
try {
// some code
} catch(SomeException e) {
throw new DatabaseException();
}
}
}
regards,
The only way I've found to do what I want, is to force the manager to write to the db using manager.flush(), and then catch the PersistenceException that that throws. I can then log the database error as I want, and throw an EJBException to force rollback. Leaving the container to do the flush seems to irretrievably lose any useful messages with TopLink.
I have the same question : how to get the SQL error message generated from JPA?
I haven't found the solution either but, I added this line in my persistence.xml
<properties>
<property name="toplink.logging.level" value="FINE" />
</properties>
and now, I can see the sql commands issued.
Reference :
http://www.jairrillo.com/blog/2008/09/04/introduction-to-jpa-part-1-getting-started/