We can talk 3 hours about transaction and BPEL and Integration. But I will try to to it quickly.
It is a common mistake to usetransaction in OpenESB. Transactions have been created in OE especially at the time where people though that transaction was a mandatory feature. Google, Amazon and consorts showed us it is not the case.
First thing you have to know, is that the BPEL does not contain any transaction manager and is not able to create a transaction by himself. So if you ask the BPEL to manage a transaction you must provide one to it.
So the BPEL consumer has to generate a transaction and send it to the BPEL. I don't think your consumer does it.
Now, in 99% of the cases, there is no need to set atomic to true when you use a database.
Atomic MUST be used to define when an ACK is send back to the BPEL consumer.
If an error occurs in your database you must choose the compensation to fix it but not a transaction which at the end will be inefficient in an integration project. You Are not in a JEE World but in the integration world.
Yes you are right !!!
Atomic postpone the ACK returned to the JMSBC at the end of the process and when if you have a fault or an Error when inserting a row in your database you can deal with and exit from your provcess and don't consume your message from your JMS Queue if needed.
I never said don't use Atomic. Atomic is Critical to improve the guarantee of delivery of your process. I just said don't use transaction. From my point of view, transaction in an integration project is useless and create many issues.
Many disagree with me I suggest them to express their point of view in that post ;-)
This post has NOT been accepted by the mailing list yet.
I had tried not to set the transaction in the WSDL but however it return me failed. If I set the BPEL to atomic, I encountered table lock no matter I had set the transactions to be NOTransaction or XATransaction.
Do you have any example on the Atomic and DatabaseBC which your could share ?
SO I developed a very simple application where my input channel is JMS (OpenMQ 5.x) and the outbound channel MySQL.
I tested it without and with Atomic and I was able to create records in the database.
Then I tried to understand why your project was not working and I started to play with the transaction parameters in the BPEL. There, I got the same problem than you. I was not able to insert any row and DB behaviour is the same than a lock on the table.
Please check in your BPEL if the BPEL parameter Atomic tx Attribut is set to N/A
the rebuild your project. Before a redeployment, remove the existing look in the DB.
Redeploy and Run your application then it has to work.
The reason for that is a bit long to Explain. No Time today
I'll do my best to give a longer explanation later
Please tell me if it work
As explained in my previous email, transaction is not a feature to use in an integration project.
In your example, you just want to link a between a Queue and a Database and you would be happy to duplicate a familiar behaviour such as the one you found in the JEE world.
What will you do if you have to integrate in the same process SAP, C# applications, a mainframe with MQ Series and Oracle DB. in this case, you can not rely on transaction when the case is a bit more complex than the tutorials for beginners.
So to reply to your question: Let's take a simple example: In your process you get a message from a queue, insert it in a database then generate an error.
The JMS case is easy. the broker keeps a message until it receives an ack from the client. So in openESB, the ack is given by the done message generated by the BPEL. (see JBI specification for more detail).
When the BPEL is set to atomic, the done is sent at the end of the BPEL. So if you have an error before or an exit, you will not send an ACK to the JMS broker and consequently your message will be kept in the Queue,
Regarding the insert you made in the DB, to cancel don't use transaction of course, so you have to create a compensation in your process that will be triggered when an error occurs in your process . In the compensation scope, you delete the row you insert. The Compensation is made for this type of Use Case.
So, it is a bit more complex to Develop, but that works with any type of DB.
certainly in a future, You will work not with a RBDS such as Oracle or MySQL but with a NoSQL DB (ex Cassandra).
What utility will be the transaction you want to use today. The transactions are obsolete and I would advise you and all the integration developers and architect to learn new approaches to replace them .
This post has NOT been accepted by the mailing list yet.
Understand that the broker will keeps the message and the inserting to a database if generate an error, I could use the compensation method.
But if a message was sent to the broker and it encountered error at the insert part how to roll back the message which had been sent to the broker. Any other method could I use to rollback or delete the message in the broker ?
In my last email, I just wanted to give you a flavour on how to manage a world without transaction.
You can find many many cases more and more complex to justify the transaction use. It is not the right approach.
As I explained to you Transaction belongs to the past and using Transaction push you to work with less and less platforms that could work with 2 phases commit only. it would be ridiculous. You need to Design your process to work with any type of partners
In integration, there are three compensation types. The first type is the complete compensation such as the one with a database.
In some other case (ex: writing in a log file), the compensation can be partial only (you don't destroy the original message). You write a message in your process happy way and when an error occurs you write a second message saying that you cancelled the first message.
Let's take an example in the real life. Your girl Friend is abroad and you send her a letter saying you want to split up. After one day, you change your mind. So what could you do? Either you send a second letter saying that you regret (but the first letter remains in her mind) or you go abroad to fix the issue.
So in computer technologies is the same thing. Either you send a second message that cancel the first one. It is a partial compensation (second type) or you create a manual process to fix it since we believe that exception are exceptional. (third type)
You can also discuss with the business to create a lightly change in the business process and make easier your compensation. That works well when you share your concern with the business team.
It is Exactly what you have to do with your example.
" JUST RECORD YOUR MESSAGE IN THE DATABASE BEFORE SENDING THE MESSAGE IN THE SECOND QUEUE"