Hello,

I am confused about persistence with request response operations.  There
is a persistence point after a send shape, but what happens when the req-res
p
operation happens within an atomic or long running scope?

For example, if I had:

Orchestration with a long running scope, within that scope is a one way send
shape followed by a request response (HTTP).  Both request and the response
shapes live within the scope.

My understanding is that in a scope, the messages are not sent until the
transaction is committed.

If I had 2 one way send shapes, I would save a persistence point, how can
that be possible with the request response becuase the request side can obvi
ously
not wait until the end of the transaction because the response is expected
before it ends?

Can someone explain this to me? http://msdn.microsoft.com/library/e....asp?frame=true
does not explain this case.

Thanks!

BA

[ Post a follow-up to this message ]

Hi,

You have to look at "long running" and "atomic" transactions separately.

"Long Running" Transactions are logical process transactions (business
transactions) and do not correlate to database transactions. In other words,
when sending documents within a long running transaction, BizTalk is free to
use as many internal atomic transactions as desired. Long Running
Transactions are a mechanism to define compensation (by means of actions
reverting previous changes) and to define time bounderies.

"Atomic" transaction are DTC transactions and, thus, define database
transactions. As BizTalk is conducting external messaging (no matter wether
synchronous or asynchronous) via the message box, it is not possible to have
a Send and Receive shape for a Solicit-Response Port action within the same
transaction as the Sending operation is persisted with the transaction being
comitted and the receive can only be done after the adapter has completed
interaction. Thus, for that, you need two atomic transactions, the first
spanning upto the send, the second starting at the receive.

Sincerely

Joerg Fischer
BizTalk MVP

"BA" <biztalk.architect@gmail.com> schrieb im Newsbeitrag
news:7127ff7bc1738c7e0ed0e05387a@news.microsoft.com...
>
> Hello,
>
> I am confused about persistence with request response operations.  There
> is a persistence point after a send shape, but what happens when the
> req-resp operation happens within an atomic or long running scope?
>
> For example, if I had:
>
> Orchestration with a long running scope, within that scope is a one way
> send shape followed by a request response (HTTP).  Both request and the
> response shapes live within the scope.
>
> My understanding is that in a scope, the messages are not sent until the
> transaction is committed.
>
> If I had 2 one way send shapes, I would save a persistence point, how can
> that be possible with the request response becuase the request side can
> obviously not wait until the end of the transaction because the response
> is expected before it ends?
>
> Can someone explain this to me?
> http://msdn.microsoft.com/library/e...me=tr
ue
> does not explain this case.
>
> Thanks!
>
> BA
>
>

[ Post a follow-up to this message ]

Hello Joerg,

Thanks for helping to clear this up.  So what I take from this is that long
running scopes do not save persistence points, in fact it adds one at the
end of the scope itself.  Only an atomic scope actually conserves a persiste
nce
point if you have multiple (non req-resp) send operations within it.

BA
http://biztalkia.blogspot.com/

[vbcol=seagreen]
> Hi,
>
> You have to look at "long running" and "atomic" transactions
> separately.
>
> "Long Running" Transactions are logical process transactions (business
> transactions) and do not correlate to database transactions. In other
> words, when sending documents within a long running transaction,
> BizTalk is free to use as many internal atomic transactions as
> desired. Long Running Transactions are a mechanism to define
> compensation (by means of actions reverting previous changes) and to
> define time bounderies.
>
> "Atomic" transaction are DTC transactions and, thus, define database
> transactions. As BizTalk is conducting external messaging (no matter
> wether synchronous or asynchronous) via the message box, it is not
> possible to have a Send and Receive shape for a Solicit-Response Port
> action within the same transaction as the Sending operation is
> persisted with the transaction being comitted and the receive can only
> be done after the adapter has completed interaction. Thus, for that,
> you need two atomic transactions, the first spanning upto the send,
> the second starting at the receive.
>
> Sincerely
>
> Joerg Fischer
> BizTalk MVP
> "BA" <biztalk.architect@gmail.com> schrieb im Newsbeitrag
> news:7127ff7bc1738c7e0ed0e05387a@news.microsoft.com...
> 

[ Post a follow-up to this message ]