I have a stateless session bean which is annotated as container managed transaction, but I don't define transaction type. surprisingly the methods of this bean don't throw JPA exceptions. would you please explain why this is happening?
According to java ejb3_1 specification:
REQUIRED is the default transaction attribute value for container managed transaction demarcation. The explicit specification of the transaction attribute is therefore not required.
Related
I have a problem with a caught RuntimeException marked as #ApplicationException(rollback=true) rolling back my database transaction and killing the transaction for the following actions.
#ApplicationException(rollback = true)
public class XyzValidationException extends RuntimeException {
...
}
The process is a batch import process, which is importing mass data in chunks. When the transction is rolled back, the whole chunk is rolled back and after that selected for import again, so the whole thing repeats in an endless loop.
The applicationserver is a JBoss 7.1 and the database is an Oracle 11.2.
I want to catch the exception, mark the import source entity as faulty, log something, and carry on with the rest of the data.
But catching the exception doesn't prevent the transaction from being rolled back. I have read about it now and understood this behavior is normal.
But the thing is, how do you do it then? How do you configure the exception to not roll back when it's caught, and to still do a rollback, when it's uncaught?
I could set the exceptions' annotation to #ApplicationException(rollback=false), but then i would prevent a rollback in a situation, where the exception is thrown an not caught, right?
In other processes, a Rollback could be sensible, when this exception is thrown. There, I would just not want to catch ist.
Does anyone have an idea, how I could achieve this?
I have tried already to change the exception to a checked exception (... extends Exception) and left the annotation with rollback=true.
It didnt change the behavior (I was thinkig/hoping that the rollback=true would maybe just take effect on an uncaught exception, and do the trick in my case... but no)
Then I tried the checked exception with rollback=false, and as expected, it did the trick. But as described already, I don't want to deactivate the rollback completely... only when the exception is caught.
And, if possible, I'd like to stick to the RuntimeException, as we have this 'Policy' to use RuntimeExceptions wherever possible, and the necessary throws-declarations would spread across the application...
Thanks in advance...
Frank
You have different ways how to manage this problem.
Use application exceptions. By default, all checked exceptions are application exception (except the RemoteException). In the CMT model, such kinds of exceptions don't cause an automatic rollback. Thus, you can handle occurred exception during processing a chunk and do something staff like log smth without rollback. For rest cases, should use unchecked exceptions which cause an automatic rollback.
If you have some "policy" sticking to unchecked exceptions in your code. You can declare runtime exception like XyzValidationException and annotate it with #ApplicationException(rollback = true), so in the case where it is thrown the transaction won't be rollbacked. For all other code, where there is necessary to make rollback you can use RuntimeException (which has rollback = false by default).
Have a look at CDI if it's possible in your project. It provides #Transactional which includes such properties as rollbackOn and dontRollbackOn.
I'm using a custom Jersey ExceptionMapper to map my unchecked exceptions into error responses (as described in the documentation). My problem is that the transaction is not rolled back, every DB modification made before the exception is persisted.
The same thing happens if, instead of using the ExceptionMapper, I throw a WebApplicationException.
How can I send an error response to the client preserving the normal behavior (rollback the transaction)?
I found a similar question here, but I don't use spring.
What you can do is use a RequestEventListener to manage the transaction throughout the lifetime of the request. You can listen for RequestEvent.Types, which includes events such as RESOURCE_METHOD_START, ON_EXCEPTION, RESOURCE_METHOD_FINISH, etc. You can begin the transaction at the beginning of the request processing and commit or rollback the transaction depending on if it a successful processing or an exception is thrown.
This is pretty much what Dropwizard does with it's #UnitOfWork. You can see how it is all implemented in this package. Look at the UnitOfWorkApplicationEventListener. You'll see how they implement what I was talking about above.
Are there any docs on how to correctly implement ExceptionFilterAttribute? For instance:
What happens when you set context.Result? Will it serialize that result as the overall response? Does it stop applying any further filters?
What happens when you set context.ExceptionHandled? Does that mean "I'm done processing exceptions, please send the response to the client", or does that mean "I've recovered from the exception, continue processing the request"?
When do you call base.OnException or base.OnExceptionAsync, at the beginning or the end? Do you only call it when your implementation doesn't handle the given exception?
Etc.
There's no official doc on this and it's not the most obvious thing to implement, so does anyone have either a) good docs - maybe a blog post, or b) a correct sample implementation?
Documentation about filters in ASP.NET Core.
Documentation about error handling.
Exception filters handle unhandled exceptions that occur in controller creation, model binding, action filters, or action methods. They won't catch exceptions that occur in Resource filters, Result filters, or MVC Result execution.+
To handle an exception, set the ExceptionContext.ExceptionHandled property to true or write a response. This stops propagation of the exception. Note that an Exception filter can't turn an exception into a "success". Only an Action filter can do that.
Exception filters are good for trapping exceptions that occur within MVC actions, but they're not as flexible as error handling middleware. Prefer middleware for the general case, and use filters only where you need to do error handling differently based on which MVC action was chosen.
Regarding "Does it stop applying any further filters?":
Further pipeline execution is stopped if you have unhandled exception, as current method execution is stopped) and exception go up the stack until it is caught in a higher level catch block.
But keep in mind, that final implementation of ExceptionFilterAttribute logic is still in progress. Some changes are expected in next .NET Core MVC 1.1.2.
I have found the following useful explanation is github issue (Exception Filters returns an empty body):
Have confirmed IActionFilters in MVC 5.2.3 and ASP.NET Core 1.1.0 behave the same. However, IExceptionFilters behave differently w.r.t. setting Result but leaving ExceptionHandled==false. Should remove this special case around setting Result.
1.1.0 behaviour is also a regression compared to ASP.NET Core 1.0.x.
Long story about a consistent behaviour for ASP.NET Core:
Users can short-circuit most IFilterMetadata implementations by setting Result. But, only on the way in e.g. OnActionExecuting() can short-circuit but OnActionExecuted() cannot.
To short-circuit IExceptionFilter implementations (which are only called on the way out), users must set ExceptionHandled==true.
Setting ExceptionHandled==true in all IFilterMetadata implementations also ensures an Exception thrown in an action is not rethrown. An overridden Result is used in that case.
In a small, intentional deviation from MVC 5.2.3, setting Exception==null is handled identically to setting ExceptionHandled==true.
I have a question regarding how global exception strategy will be applied by mule for an application using multiple configuration XML files.
Let me try to explain my confusion. Assuming that I have 4 mule configuration XMLs (each mule config XML has one or more flows) in my application and out of these 1 has defined a global exception strategy. Other config XMLs have flows that don't have any custom exception handling i.e. they use the default exception strategy provided by mule.
Now the question is -- "While the application is running if it encounters an exception and the exception happens in of flow which is defined in the XML without global exception strategy"
Will this exception be handled by the the global exception strategy defined in one of the XML's? OR handled by config XML containing the flow.
My expectation is that the global exception strategy defined in a particular XML file will ONLY handle the exceptions that occur in the flows within that XML only.
However I will appreciate if you guys can shed some more light on this subject.
When Mule loads multiple XML configuration files, it behaves as if there was only one, ie all the globally defined elements (transformers, components, security managers and exception strategies) are available to all flows everywhere.
To use the global exception strategy across all other configuration Xml files in the project, define a global Configuration.
E.g. If the global exception strategy is defined in 'global.xml', in that xml -> go to Global Elements - Add a new 'Configuration' and choose the defined global exception strategy in the dropdown 'Default exception strategy'.
The handlers I implemented override SimpleChannelHandler messageReceived, channelConnected and exceptionCaught methods.
Throwing a base Exception type means PMD complains "Signature Declare Throws Exception".
What is the best way to handle Netty exceptions so as not the throw base Exception types?
My guess is to remove the "throws Exception" from all my handlers. Then any exception that occurs will eventually get propagated up to the exceptionCaught() method in the last upstream/downstream Handler in the pipeline. Is this a correct assumption?
Although I happen to agree with PMD on this, the object model of Netty is different and uses a raw Exception. If you are programming against the Netty API, it would probably be better (for consistency, readability, etc.) to follow their model.
Don't let a static analysis tool be the deciding factor on your code. Sometimes there are exceptions (nice pun, not intended)