Now once we have understood the insight of a synchronous and asynchronous BPEL process we will take a look in to the manaual recovery.What happens in manual recovery why does a process goes in to manual recovery,what does it actually store.
We will again have a deep look in the process.
Let suppose client provide an input .As soon as the message is arrived two things happen simultaneously,the message is stored in to the ORABPEL table invoke_message and it is passed to the dispatcher.The dispatcher sends this message to the JMS queue which is nothing but the delivery queue we have seen earlier.Once the data reach the queue a worker bean(MDB) invokes the onMessage() method.The method retrieve the information from the dispatcher and execute the process.
Now lets see when can a rollback happen
Let suppose database is down so the message will not be stored in the message_invoke table but at the same time the message will be passed to the dispatcher for further processing of the flow.However since the data couldn't get stored in the database this will be a JTA failover so instance will be forced to move to the recovery queue.
Again if the JTA transaction took time more than the expected that is greater than the time our the process will again go the manual recovery.
Here one important thing to understand is that the jms queue is not a database but a small in-memory queue and can not be accessed outside the bpel process manager.The use of JMS And MDB has been removed in 10.1.3.4 as JMS was not efficient.The queue was unbounded and some times due to heavy load and depending upon the environment and inbound/outbound scenario it gets filled and causes the process to go to manual recovery.
so in all there are several reason for a process to go in to manual recovery
1>It may be due to database down.
2>Server crashed in between.
3>Jta transaction time out.
I already have posted in my previous updates how to change time out.
The process which does not complete successfully goes in to the manual recovery console .The manual recovery is simply a query against the
invoke_message and work_item tables for invoke messages and activities,
respectively.
We can implement the logic for autmatically recover the BPEL process and it has been mentioned in brief in the SOA Suite best practice guide.
No comments:
Post a Comment