couple of links you might be interested in
http://msdn.microsoft.com/en-us/library/ms173763.aspx
http://support.microsoft.com/kb/237686
mayo sent the following on 4/27/2009 12:56 PM:
> I found out more about how the deadlock is happening, but first let me say
> that setting the isolation level to read-uncommitted worked. Does anyone
> have any experience using read-uncommitted with OFBiz 4.0 on MSSQL? I
> cannot figure out the logic behind the process threads in the database, but
> I've meticulously stepped through the code to find out when they are
> created. Can anyone tell me if this is characteristic of the 4.0 thread
> logic and is different/fixed in the trunk logic?
>
> ---------------
>
> The first thread, lets say thread-A, is used to start the creation of the
> order. It looks like a second thread, thread-B, is created to handle "side
> jobs" like updating and selecting from the JOB_SANDBOX and to get the
> SEQUENCE_VALUE for an entity. I was incorrect in saying synchronous
> executions start a new thread because thread-A continues to handle almost
> every command in the main process flow.
>
> The first block comes in the createOrder method. When
> "addSuggestionsToShoppingList" is triggered, Thread-A inserts a row into
> JOB_SANDBOX. When Thread-B continues its "side jobs" and tries to run an
> update on JOB_SANDBOX, but it cannot because Thread-A has an open
> transaction. This block doesn't freeze the application, so if the next
> event didn't happen, everything would be fine.
>
> The second block (and deadlock) happens when I try to call
> runAsync("sendEmailConfirmation"). The main process flow begins to enter in
> new RuntimeData and JobSandbox entities with storeAll(). The
> GenericDelegator goes to locate the primary key for the RuntimeData with a
> select statement. For some reason a third thread, Thread-C, is used to do
> this select statement--maybe because Thread-B is blocked. When Thread-C
> executes the select on RUNTIME_DATA, the deadlock occurs because Thread-B
> previously inserted on RUNTIME_DATA, but can't finish.
>
> To summarize the confusion, Thread-A is waiting on Thread-C, who is waiting
> on Thread-B, who is waiting on Thread-A. According to the code, everything
> is using the same transaction. The only time I see the main transaction is
> suspended is to run the payment services, but this code executes fine. I can
> see how my code facilitates the problem by executing all the methods and
> services to create a full order, but I this it is the pool/thread logic that
> creates the deadlock.
>
> ---------------
>
> Does this happen to spark anyone's memory about a problem they've had with
> OFBiz 4.0? Even though ReadUncommitted may work, I want information to
> decide if I will need to backport the trunk pool logic.
--
BJ Freeman
http://www.businessesnetwork.com/automation
http://bjfreeman.elance.com
http://www.linkedin.com/profile?viewProfile=&key=1237480&locale=en_US&trk=tab_pro
Systems Integrator.
