#15 Deadlock under multithreadded use.

[Anonymous]

This is a bit vague - sorry about that.

We have some objects which are used by JSPs and all
share a single database connection. When multiple
instances of the JSPs were run with the 2.0.7 driver
all was fine, but under the 2.0.11 there is amost
immediate deadlock (or at least all instances hang).

Sorry we can't give more details - feel free to remove
this report if you feel it is too vague to be of help.

[Mark Matthews]

Logged In: YES
user_id=116907

Can you give me an overview of your order of operations
with the JDBC API? Also, it's usually not good practice to
use JDBC like this, that's why connection pools were
invented...however, I'd like to make sure that the driver
supports this correctly.

[Nobody/Anonymous]

Logged In: NO

Sorry for the delay in this response (I originaly replied
to the mail)

Thanks for the response. I would just like to say that I
think your driver is an excelent peice of work and my life
(not to mention other peoples) would be rather difficult
without it.

Anyway. What we are doing is basically rather simple but
could be wrong. I am quite willing to considder errors in
our code as culprits - but I thought it may be helpful to
notify you as this may be a problem in the driver.

I would have included some java files in case you wanted to
go through the code but I don't have permission to post
bits of the project publically - I can mail them to you in
person if you wish. The general order of opperations for
each thread is something like:

Call the create method on the objects DBPersist class.
The synchronised method calls any pre-requisite create
methods.
It then gets a prepared statement to do the create.
The parameters on the statement are set.
The connection is shared between all prepared statements in
all persistance classes.
The results are used.
The result set is closed.
The syncronised create method exits.

NOTE: The persistence methods are only synchronised within
their class and not against the connection its self. I
presumed that the driver was thread safe and could handle
multiple calls to execute queries. On reflection this was
possibly a dangerous assumption.

[Mark Matthews]

Logged In: YES
user_id=116907

Could you try 2.0.12 for me?

[Nobody/Anonymous]

Logged In: NO

We have now upgraded to 2.0.13 and there are no deadlock
problems so far. We went to 2.0.12 but had Unicode
problems, although it looked like the deadlock was fixed in
2.0.12.

All is well and good with 2.0.13 - thanks for bearing with
this somewhat vague support request.

Thanks for maintaining a great product.

[Nobody/Anonymous]

Logged In: NO

I have had a similar problem using Resin 2.1.0 and the 2.0.11
mm.mysql driver. I have a connection manager class that has
a thread that checks the status of the connections regularly.
every so often, accessing these connections would kill other
threads. A stack dump from resin shows a definite deadlock:

FOUND A JAVA LEVEL DEADLOCK:
---------------------------
t@14 waiting to lock
object@0xfa7f17a4:"org/gjt/mm/mysql/jdbc2/IO"
which is locked by t@13
t@13 waiting to lock
object@0xfb8515d0:"org/gjt/mm/mysql/jdbc2/Connection"
which is locked by t@14

JAVA STACK INFORMATION FOR THREADS LISTED ABOVE:
-----------------------------------------------

Java Stack for t@14 (EE = 0x7457b0) "Thread-2" :

[1] org.gjt.mm.mysql.Connection.isClosed(Unknown Source)
[2]
org.mysql.ConnectionManager$ConnectionManagerThread.run
(ConnectionManager.java:103)

Java Stack for t@13 (EE = 0x722408) "Thread-1" :

[1] org.gjt.mm.mysql.Connection.getCatalog(Unknown Source)
[2] org.gjt.mm.mysql.Statement.executeUpdate(Unknown
Source)
[3] org.gjt.mm.mysql.jdbc2.Statement.executeUpdate
(Unknown Source)
[4] org.stats.Handler.tally(Handler.java:29)
[5] Statsd$StatsThread.run(Statsd.java:113)
-----------------------------------------------
Found 1 deadlock

I hope this can expound on the earlier post and lead to a
resolution of the issue. For now i have reverted back to
driver version 2.0.7.