|
Home > Archive > BizTalk Server Orchestration > September 2005 > Orchestration transaction types
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]
| Author |
Orchestration transaction types
|
|
| Jeremy Chapman 2005-09-15, 5:59 pm |
| I've looked over the documentation, and I can't find suitable explanation
about transaction types. When would I pick atomic over long running or vice
versa?
I have a few scenarios where I need to pick transaciton types.
The first orchestration calls a business rule, so the orchestration needs a
transaction type. Which type would be the wisest to use?
A second orchestration calls the first orchestration, so the second
orchestration needs a transaction type because the first orchestration has
one. Which transaction type would I then use for the second orchestration?
| |
| Paul Brinkley-Rogers 2005-09-19, 2:48 am |
| You would need both orchestrations set to long-running transactions, with
your Call Rules shape contained in an Atomic scope.
Paul Brinkley-Rogers
"Jeremy Chapman" <me@here.com> wrote in message
news:%239MAeujuFHA.3764@TK2MSFTNGP09.phx.gbl...
> I've looked over the documentation, and I can't find suitable explanation
> about transaction types. When would I pick atomic over long running or
> vice versa?
>
> I have a few scenarios where I need to pick transaciton types.
>
> The first orchestration calls a business rule, so the orchestration needs
> a transaction type. Which type would be the wisest to use?
> A second orchestration calls the first orchestration, so the second
> orchestration needs a transaction type because the first orchestration has
> one. Which transaction type would I then use for the second
> orchestration?
>
>
| |
|
| Hi Jeremy,
You would also have to consider what shapes were going to be in the
transaction scope and serializing of objects etc. Also you would need to
determine for instance when you require a send port to send or a receive port
to receive as these don't happen in atomic transactions until the transaction
has committed.
Atomic transactions also dont allow for nested transactions or exception
handlers, whereas long running transactions do.
I think that there is also something with atomic transactions not allowing a
request -response that use the same correlation set.
Gary
"Paul Brinkley-Rogers" wrote:
> You would need both orchestrations set to long-running transactions, with
> your Call Rules shape contained in an Atomic scope.
> Paul Brinkley-Rogers
>
> "Jeremy Chapman" <me@here.com> wrote in message
> news:%239MAeujuFHA.3764@TK2MSFTNGP09.phx.gbl...
>
>
>
|
|
|
|
|