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.
--
View this message in context:
http://www.nabble.com/MS-SQL-and-OFBiz%2C-database-locks-on-transactions-tp23225473p23263811.html
Sent from the OFBiz - User mailing list archive at Nabble.com.
