|
Home > Archive > BizTalk Server Orchestration > June 2004 > Variable inside Orchestration
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 |
Variable inside Orchestration
|
|
| Enrico 2004-06-20, 11:09 pm |
| Hi,
when i define a variable inside an orchestration is a global variable?
If yes there is a impact about the performace for entire orchestration?
Enrico
http://blogs.dotmark.net/enf/
| |
| Alan Smith 2004-06-20, 11:09 pm |
| Hi Enrico,
When you define an orchestration vaiable, it will have the scope of the lifetime of the orchestration instance, the same way as a member variable is in the instance of a class. (You could call it global as far as the orchestration instance is concerned.)
Yes, there are performace implications for this. If your orchestration dehydrates, and rehydrates, the orchestration variables will be serialised into a SQL database, along with the orchestration state, (this is why you need to make any classes you use as
orchestration variables serialisable).
For int and string types, it's not relly an issue (unless the strings get long), but for larger objects, it will be.
One way to declare a variable that is not an orchestration variable is to create a scope shape, and set the transaction type to "Atomic". You can then declare variables for that scope shape, which will have less of an impact on performance.
Hope this helps,
Alan
"Enrico" wrote:
> Hi,
> when i define a variable inside an orchestration is a global variable?
> If yes there is a impact about the performace for entire orchestration?
>
> Enrico
>
> http://blogs.dotmark.net/enf/
| |
| Christof 2004-06-20, 11:09 pm |
| Declaring variables is about reserving memory, which does not have any
impact on performance. Scoping should be done based upon knowledge about
where the variable is exactly needed in your orchestration.
Best regards,
Christof
"Enrico" <Enrico @discussions.microsoft.com> wrote in message
news:A0D03E97-15EF-4506-9BF7-486A1231B6E2@microsoft.com...
> Hi,
> when i define a variable inside an orchestration is a global variable?
> If yes there is a impact about the performace for entire orchestration?
>
> Enrico
>
> http://blogs.dotmark.net/enf/
| |
| Lee Graber [MSFT] 2004-06-20, 11:09 pm |
| To clarify, orchestration variable lifetime is tied to the scope in which
they are defined. When the scope ends, you can no longer reference the
variable and it will no longer be serialized as part of the orchestration
state. The main perf impact, as described below, is the serialization and
storage of these variables if a schedule reaches a persistence point. In
general, this is a negligible hit since most variables are ints or strings.
If you have a variable whose serialization is expensive, you should try to
scope the variable appropriately instead of making it unneccesarily global.
For message objects, we actually do some internal work to try to make sure
we limit the scope of message variables so that once you have passed a
persistence point where they are no longer needed, we release the reference
to the message. One important thing to note is that I just said scope, not
atomic scope. Atomic scopes do not confer any additional features in
regards to variable lifetime. Atomic scopes, though, can decrease your
performance if you add an atomic scope around shapes which would not cause
persistence (ie no sends or execs). The end of an atomic scope is always a
persistence point, which is a very expensive operation. So if you are
really worried about variable lifetime, use a simple scope, not an atomic
scope.
HTH
Lee
PS: In august, I believe, I will be giving a performance webcast which will
go into much more detail about persistence and persistence points, or if
you can get access to the dvd, I gave a talk at teched 2004 on this topic.
This posting is provided "AS IS" with no warranties, and confers no rights.
EBusiness Server Team
--------------------[vbcol=seagreen]
lifetime of the orchestration instance, the same way as a member variable
is in the instance of a class. (You could call it global as far as the
orchestration instance is concerned.)[vbcol=seagreen]
dehydrates, and rehydrates, the orchestration variables will be serialised
into a SQL database, along with the orchestration state, (this is why you
need to make any classes you use as orchestration variables serialisable).[vbcol=seagreen]
long), but for larger objects, it will be.[vbcol=seagreen]
create a scope shape, and set the transaction type to "Atomic". You can
then declare variables for that scope shape, which will have less of an
impact on performance.[vbcol=seagreen]
| |
| Christof 2004-06-20, 11:09 pm |
| Great job describing this Lee!
"Lee Graber [MSFT]" <leegr@microsoft.com> wrote in message
news:3r6UQXNVEHA.2980@cpmsftngxa10.phx.gbl...
> To clarify, orchestration variable lifetime is tied to the scope in which
> they are defined. When the scope ends, you can no longer reference the
> variable and it will no longer be serialized as part of the orchestration
> state. The main perf impact, as described below, is the serialization and
> storage of these variables if a schedule reaches a persistence point. In
> general, this is a negligible hit since most variables are ints or
strings.
> If you have a variable whose serialization is expensive, you should try to
> scope the variable appropriately instead of making it unneccesarily
global.
> For message objects, we actually do some internal work to try to make sure
> we limit the scope of message variables so that once you have passed a
> persistence point where they are no longer needed, we release the
reference
> to the message. One important thing to note is that I just said scope, not
> atomic scope. Atomic scopes do not confer any additional features in
> regards to variable lifetime. Atomic scopes, though, can decrease your
> performance if you add an atomic scope around shapes which would not cause
> persistence (ie no sends or execs). The end of an atomic scope is always a
> persistence point, which is a very expensive operation. So if you are
> really worried about variable lifetime, use a simple scope, not an atomic
> scope.
>
> HTH
> Lee
>
> PS: In august, I believe, I will be giving a performance webcast which
will
> go into much more detail about persistence and persistence points, or if
> you can get access to the dvd, I gave a talk at teched 2004 on this topic.
>
> This posting is provided "AS IS" with no warranties, and confers no
rights.
>
> EBusiness Server Team
> --------------------
<AlanSmith@discussions.microsoft.com>[vbcol=seagreen]
> lifetime of the orchestration instance, the same way as a member variable
> is in the instance of a class. (You could call it global as far as the
> orchestration instance is concerned.)
> dehydrates, and rehydrates, the orchestration variables will be serialised
> into a SQL database, along with the orchestration state, (this is why you
> need to make any classes you use as orchestration variables serialisable).
get[vbcol=seagreen]
> long), but for larger objects, it will be.
to[vbcol=seagreen]
> create a scope shape, and set the transaction type to "Atomic". You can
> then declare variables for that scope shape, which will have less of an
> impact on performance.
orchestration?[vbcol=seagreen]
>
|
|
|
|
|