|
Home > Archive > BizTalk Server Orchestration > May 2006 > Single threading a transaction
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 |
Single threading a transaction
|
|
| Terry Bailey 2006-05-16, 7:13 am |
| This one is a little difficult to explain. I have two orchestrations.
The first extracts a number of records from a database and breaks them up
into seperate instances via the use of an envelope schema. Having done this
it will then start a second orchestration passing a message as a parameter.
The may be several instances of this orchestration running at any one time as
the result of using an evelope.
The second orchestration then calls a database stored procedure (not MSSQL)
via an adapter to update another database. However the requirement is that
this stored proc must not be called while there already an instance of it
running. The use of a semaphore would prevent this however it is just
possible under heavy load that this would cause timeouts of the call to the
adapter.
Sensibly it would be nice to drop the send and receive shapes that represent
the call to the stored procedure into a scope shape and make this scope
atomic. However, this situation is specifically excluded for atomic shapes as
the send and the receive go to the same two way port.
Is there a way around this.
Any help in this or any pointer to some information on this sort of problem
would be helpful
Thanks in advance
Terry
| |
|
|
Terry,
I'm not sure of the reason you are splitting using an envelope, but it sounds
like you might want to abandon the message splitting and process all the
records in a loop from your original orchestration, that way you can make
each SP call in sequence and not risk multiple SP executions at the same
time.
Also, you wouldnt have to use an atomic scope for this.
Your message size or another circumstance might not make this suggestion
possible.
BA
http://biztalkia.blogspot.com/
> This one is a little difficult to explain. I have two orchestrations.
> The first extracts a number of records from a database and breaks them
> up
> into seperate instances via the use of an envelope schema. Having done
> this
> it will then start a second orchestration passing a message as a
> parameter.
> The may be several instances of this orchestration running at any one
> time as
> the result of using an evelope.
> The second orchestration then calls a database stored procedure (not
> MSSQL) via an adapter to update another database. However the
> requirement is that this stored proc must not be called while there
> already an instance of it running. The use of a semaphore would
> prevent this however it is just possible under heavy load that this
> would cause timeouts of the call to the adapter.
>
> Sensibly it would be nice to drop the send and receive shapes that
> represent the call to the stored procedure into a scope shape and make
> this scope atomic. However, this situation is specifically excluded
> for atomic shapes as the send and the receive go to the same two way
> port.
>
> Is there a way around this.
>
> Any help in this or any pointer to some information on this sort of
> problem would be helpful
>
> Thanks in advance
> Terry
| |
| Terry Bailey 2006-05-19, 7:15 am |
| Thanks BA for the suggestion, it make sense but I still have the single
thread problem.
I am processing a sequence of records that I have no real control over the
delivery of. The records are sent to me in a specific order and must be
processed in that order.
I did what you suggested and debatched them manually and this works fine
unless I get a second batch in while the first is still processing. This
kicks off a second instance of the orchestration and from that point
everthing goes downhill.
I need to make it so that there can only ever be one instance of the
orchestration running and I need to make sure that I get ordered delivery to
that orchestration of any batches that are submitted, and yes I do realise
that potentially this can cause a backlog of messages, however the delivery
is likely to be very irratic with large batches arriving in a short time but
then very long periods of inactivity which will allow us to catch up.
I know single threading also means that if the orchestration get suspended
for any reason then all processing will stop. In fact this is exactly what we
want.
I cant believe that this senario has not been seen before, is there anyone
who had had this requirement and solved it who could let me know how they did
it.
Thanks
Terry
| |
| WenJun Zhang[msft] 2006-05-23, 7:15 am |
| Hi,
This may not be a recommended operation but it does help in some cases as
work around. If you want to control the orechestration instance number,
please see the LowWatermark and HighWatermark attributes:
BizTalk Server 2004 Performance Characteristics
http://msdn.microsoft.com/library/d...-us/BTS_2004WP/
html/04d20926-20d2-4098-b701-52238a267eba.asp
Best regards,
WenJun Zhang
Microsoft Online Partner Support
This posting is provided "AS IS" with no warranties, and confers no rights.
| |
| Greg Forsythe 2006-05-23, 1:15 pm |
| Try this example from Stephen Thomas
http://www.biztalkgurus.com/Samples...hestration.html
Greg
"Terry Bailey" <brynn@nospam.nospam> wrote in message
news:9C677AE3-4F94-43E3-B926-BC35A44E9414@microsoft.com...
> Thanks BA for the suggestion, it make sense but I still have the single
> thread problem.
>
> I am processing a sequence of records that I have no real control over the
> delivery of. The records are sent to me in a specific order and must be
> processed in that order.
> I did what you suggested and debatched them manually and this works fine
> unless I get a second batch in while the first is still processing. This
> kicks off a second instance of the orchestration and from that point
> everthing goes downhill.
>
> I need to make it so that there can only ever be one instance of the
> orchestration running and I need to make sure that I get ordered delivery
> to
> that orchestration of any batches that are submitted, and yes I do realise
> that potentially this can cause a backlog of messages, however the
> delivery
> is likely to be very irratic with large batches arriving in a short time
> but
> then very long periods of inactivity which will allow us to catch up.
>
> I know single threading also means that if the orchestration get suspended
> for any reason then all processing will stop. In fact this is exactly what
> we
> want.
>
>
> I cant believe that this senario has not been seen before, is there anyone
> who had had this requirement and solved it who could let me know how they
> did
> it.
>
> Thanks
> Terry
|
|
|
|
|