It's fairly simple, the code you have written (including configuration
settings for service defs, etc) has caused a deadlock. To fix it,
change your code.
As for MySQL versus MSSQL... well... it is an oft-lamented fact that
MySQL is not as strict as other databases about pesky things like
"transactions" and "foreign keys". Of course, in this case it may
simply be different transaction isolation levels you are using for the
different databases. It is certainly the case the a deadlock in one tx
isolation level will have no problem in a less strict one.
-David
On Apr 25, 2009, at 7:19 AM, mayo wrote:
The reason I think it's deadlock is because when I kill the
"blocker" process
in the database, OFBiz becomes unfrozen. I will run a profiler to
make sure
that both processes are hitting the RUNTIME_DATA table, but other
than that
how would I verify even more that it is the problem? What do you
think the
problem is? Since it does not happen in MySQL, does this mean a
setting in
MSSQL or the driver would make it work and does it still mean the
pool is
the problem?
David E Jones-3 wrote:
I would HIGHLY recommend verifying that is the problem before
trying
to fix it (mainly because I don't think that is the problem).
--
View this message in context:
http://www.nabble.com/MS-SQL-and-OFBiz%2C-database-locks-on-transactions-tp23225473p23232044.html
Sent from the OFBiz - User mailing list archive at Nabble.com.
