|
Home > Archive > BizTalk Server General > February 2006 > Re Re Post
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
|
|
|
| Hi
I have posted this twice and not had any answers, so i am going for
persistence here! Someone must understand compensation! Anyone??
Hi
I am having trouble working out how compensations work. I have a send port
within a scope. The send port has delivery notification turned on. If i
make the scope long running then if the transaction fails, the compensation
handler is not invoked. If i make the scope atomic then the compensation
handler is invoked.
Why are they different? In the case of an atomic transaction, how can you
roll anything back if the transaction didn't succeed?
Can someone please give me some help with this.
Thanks,
Rob
| |
| Tomas Restrepo \(MVP\) 2006-02-23, 2:53 am |
| Rob,
> I have posted this twice and not had any answers, so i am going for
> persistence here! Someone must understand compensation! Anyone??
>
> Hi
>
> I am having trouble working out how compensations work. I have a send
> port
> within a scope. The send port has delivery notification turned on. If i
> make the scope long running then if the transaction fails, the
> compensation
> handler is not invoked. If i make the scope atomic then the compensation
> handler is invoked.
>
> Why are they different? In the case of an atomic transaction, how can you
> roll anything back if the transaction didn't succeed?
If a failure occurrs within an Atomic Transaction scope, no compensation is
done because Biztalk Automatically rolls the transaction back. Compensation
only occurrs for Atomic transactions *if* the transaction has already
committed; in other words, compensation is used to in these cases to undo
atomic transactions that had already been completely done.
Consider this scenario:
A long running transaction A contains two atomic transactions B and C which
are executed one after the other. Consider the case where an error occurs
inside B: B is rolled back. Now consider that B has already commited
successfully, and a failure inside C occurrs. What you want to do is
rollback C normally, then compensate transaction B to undo it's effects in a
"manual" fashion. You don't do anything for C because you had an atomic
transaction whose rollback should've returned you to a previous "valid"
state.
--
Tomas Restrepo
tomasr@mvps.org
http://www.winterdom.com/
| |
|
| Hi Tomas,
Thanks very much for your answer. The scenario i am interested in is
transactions around send shapes (with delivery notification turned on.) If i
put a send shape inside an atomic transaction and the send fails (e.g.
directory for file adapter does not exist) then the compensation handler is
invoked.
If i made the scope long running then the handler is not invoked. It is
this difference that i cannot understand? Why does one (the atomic) invoke
compensation but not long running?
Thanks very much for your help.
"Tomas Restrepo (MVP)" wrote:
> Rob,
>
>
> If a failure occurrs within an Atomic Transaction scope, no compensation is
> done because Biztalk Automatically rolls the transaction back. Compensation
> only occurrs for Atomic transactions *if* the transaction has already
> committed; in other words, compensation is used to in these cases to undo
> atomic transactions that had already been completely done.
>
> Consider this scenario:
>
> A long running transaction A contains two atomic transactions B and C which
> are executed one after the other. Consider the case where an error occurs
> inside B: B is rolled back. Now consider that B has already commited
> successfully, and a failure inside C occurrs. What you want to do is
> rollback C normally, then compensate transaction B to undo it's effects in a
> "manual" fashion. You don't do anything for C because you had an atomic
> transaction whose rollback should've returned you to a previous "valid"
> state.
>
>
> --
> Tomas Restrepo
> tomasr@mvps.org
> http://www.winterdom.com/
>
>
>
| |
| Tomas Restrepo \(MVP\) 2006-02-26, 10:47 am |
| Rob,
I don't remember the exact details at this time, but I believe this is what
is happening here:
> Thanks very much for your answer. The scenario i am interested in is
> transactions around send shapes (with delivery notification turned on.)
> If i
> put a send shape inside an atomic transaction and the send fails (e.g.
> directory for file adapter does not exist) then the compensation handler
> is
> invoked.
That is because the atomic scope has finished execution. In this case, the
message you're sending is not commited to the message box *until* the
transaction of the scope is commited. That means that, in essence, the
delivery notification only happens *after* the original transaction was
done. Again, I'm not sure here, but it seems like a plausible explanation,
though I can check the exact behavior later on.
This might be better explained if you realize that atomic scopes have very
different semantics, and, in particular, can be used to force persistence
points to only occurr in some places. For example, if you put to send shapes
inside a single atomic transaction scope, then biztalk forces a single point
of persistence right at the end of the atomic scope, so both messages are
only really "sent" (i.e. published in the messagebox) at the end of the
scope when the transaction commits. This is because all the send shapes do
is publish the message in the messagebox.
> If i made the scope long running then the handler is not invoked. It is
> this difference that i cannot understand? Why does one (the atomic)
> invoke
> compensation but not long running?
That would be here because, unlike the atomic transaction, the long running
doesn't force here biztalk to wait until the transaction commits to publish
the message, hence, when the actual error ocurrs, you might still be inside
the original long running transaction and compensation is not invoked in
this scenario automatically. For this, you'd need an exception handler,
instead.
--
Tomas Restrepo
tomasr@mvps.org
http://www.winterdom.com/
|
|
|
|
|