Why sometimes we needed to add dehydration point after reply

Reply handling

We normally think of reply as causing the response to be sent back to the client, and if the transaction was initiated by the BPEL service engine, then it would be committed as part of the reply. In most cases, this is an accurate description of the end result, but this is not actually what happens. When a reply is reached, the response message is marked as available for returning to the requestor, but it is not returned to the requestor. Instead the BPEL engine will continue to process activities until it reaches a dehydration point. On reaching the dehydration point, the current thread (which was also the requesting thread) will return the reply message to the requestor. Note that this results in a delay in the returning of the result to the requestor, and it also causes the transaction scope to extend past the reply activity.

SOA Suite: 11.1.1.4