- This topic has 1 reply, 1 voice, and was last updated 7 years, 8 months ago by
.
-
Posts
-
-
Hi All,
I have one orchestration within one send port will insert data into Item Table ( Record would be 2000 to 4000 in SQL server 2000).
Once the all records will insert successfully orchestration insert one process completion record in ItemCycle Table using Pro_InserItemCycleLog procedure.
Within Pro_InserItemCycleLog procedure i have to execute supporting existing sql procedures (ItemScrubber ) it take 10 to 15 min time.
Now my problem:
I got one Item file (Item1.xml) 9:00 AM and biztalk ll start processing on it and it takes approximate 12 min to finished all above processing, during processing system get another file (item2.xml) on 9:02 AM after 2 min
Orchestartion is took that file and wait for some time and i got an warning and after retrieval count system generate error in event log. And both transaction get suspend
Error :
Transaction (Process ID 79) was deadlocked on lock resources with another process and has been chosen as the deadlock victim. Rerun the transaction.
My Receive Port Configuration:
Advance Settings -> Polling interval = 900000 and Batching -> Number of message in a batch = 1
My Send Port Configuration
Transport Advance Option -> Retry count = 3 , Retry interval (min) = 5 priority = 5
Please guide me how to avoid deadlock. In my system Item File would be generate every 5 to 8 min. [:(]
Regards,
– Dhaval M.
-
The best fix would be to modify the stored procedures so they can be run concurrently without deadlocking. You can configure BizTalk to send the SQL messages one at a time, but the problem is that you could end up with a huge backlog of messages over time. If the SP takes 12 minutes to run, and you receive messages every 5-8 minutes, something has to give. Is there any window where you don’t receive the messages so that BizTalk will be able to finish processing the backlog?
To make BizTalk send the messages one at a time, here are some options:
1. Mark the SQL send port for ordered delivery. This should make the messages go through the port one at a time, forcing one message to complete before another one can begin. I can’t remember whether this is done in the orchestration in VS, or on the physical send port through the BizTalk admin console. Just check the settings both places.
2. Use a sequential convoy pattern. You would need to modify your orchestration to receive messages in a loop. This would mean that you would only have one active instance of the orchestration and the orchestration would control the timing of the messages sent to SQL and you could avoid deadlocks.
-
- The forum ‘BizTalk 2004 – BizTalk 2010’ is closed to new topics and replies.