No one has any ideia? Thank you!
You'd need savepoints which are not part of the jta transaction model. You might possibly be able to do this with a driver supporting savepoints and bmp and controlling transactions directly through the driver, not through userTransaction.
I would very strongly recommend you redesign what you are doing so you stop wanting this feature.
First of all, many thanks for replying me!
OK. So now I understand that I shouldn't be wanting what I want. So, in order to redesign, I need some help on how to do it. I'll be describing what I want, maybe someone can give some thoughs on this.
Lets say that I have a bank management app. I have one EJB that creates the account, one that creates the customer and one that adds the new customer to a mailing list and sends him a welcome SMS to his celular.
I want to call, on the same transaction, the three EJBs (all stateless session beans). If the customer or account creation fail, I want to rollback the whole transaction.
But if the mail registration and SMS sending fail, I want to be able to rollback this but commit the other two beans. This is considered an "optional" bean that can run later called by a reprocessor mechanism.
The only way I imagine this possible is by executing first all beans that MUST give sucess. If all goes well, commit and then execute the "optional" beans, each one in his own transaction, obtaining this way the necessary transaction isolation.
Is this the best approach or does anyone have a better idea?
Thank you again for your time!
Think about the time scale. The first 2 actions have to happen immediately. The spam signup (sorry, I couldn't resist;-) can happen at any time later, you just want to guarantee that it happens eventually.
Use transacted jms for the spam sign up: your original session bean's signup method has tx Required, it created entities A and B and posts a sign-up message to a (durable) queue all in the same transaction.
The jms services will attempt to deliver the message repeatedly: if it fails too many times, it will go into a dead letter queue (DLQ) that you can examine manually.
You can do something more like you propose by using more transactions: however I think it will have slightly different and perhaps less desirable semantics.
Thank you for you reply! We will work on the JMS solution. It seems a lot cleaner that the one we were thinking of.
The best for you! :)