The other day I had a weird defect in the application I worked on, we had a Message driven bean [MDB] calling another EJB inside the message processing code and everything was working fine and passed two different testing periods.
after going live on production something happened, the MDB received a message and invoked the EJB to do some work, that work included calling a web service, this service client thrown time out exception and thrown an exception and the EJB couldn't finish its work because that's what is expected, the weird thing is that the exact same message was reprocessed by the MDB automatically.. we don't have anything in our code that did that.
this didn't happen before with other EJBs called from an MDB..
after thorough investigation I found the following :
1- The MDB uses container transaction [ found configuration in the ejb-jar.xml] (this is used in EJB2)
2- The EJB method that was invoked also had container transaction configured with transaction attribute as Required
3- When an exception is thrown from the EJB method, it calls : context.setRollBackOnly(); which means the container transaction will roll back
but why was the message reprocessed again? Luckily in production the service didn't time out the second time and the message was processed successfully, but I did a test where the EJB always fails and that led in having the MDB reprocessing the message indefinitely until I shutdown the server.
I tried and changed the EJB transaction attribute in the ejb-jar.xml to 'RequiresNew' instead of 'Required' because at that point I felt that there is a relation between the transaction failing in the EJB and the MDB transaction [Yes MDBs have transactions] and that WORKED.
it's critical to configure the EJBs [ MDB is an EJB ] transactions to match the need of the application, in our case we didn't want the message to be reprocessed everytime it failed, so a new transaction in the EJB did the trick
istio archeticture (source istio.io) I would like to share with you a sample repo to start and help you continue your jou...
In this post I'll explain the required work to create a rest API utilizing both spring and hibernate version 4, and the configuration wi...
So RecyclerView was introduced to replace List view and it's optimized to reuse existing views and so it's faster and more efficient...
In the previous part we finished the dashboard read functionality, now we want to add the skeleton for other pages: - Login In this p...