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/

[ Post a follow-up to this message ]

Hi Enrico,

When you define an orchestration vaiable, it will have the scope of the life
time 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 orchestrati
on instance is concerned.)


Yes, there are performace implications for this. If your orchestration dehyd
rates, 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 lo
ng), but for larger objects, it will be.

One way to declare a variable that is not an orchestration variable is to cr
eate a scope shape, and set the transaction type to "Atomic". You can then d
eclare 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/

[ Post a follow-up to this message ]

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/

[ Post a follow-up to this message ]

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] 

[ Post a follow-up to this message ]

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] 
>

[ Post a follow-up to this message ]