#15 Deadlock under multithreadded use.


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

    Mark Matthews - 2002-02-12

    Logged In: YES

    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
    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

    Mark Matthews - 2002-04-16

    Logged In: YES

    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

    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:

    t@14 waiting to lock
    which is locked by t@13
    t@13 waiting to lock
    which is locked by t@14


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

    [1] org.gjt.mm.mysql.Connection.isClosed(Unknown Source)

    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
    [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.


Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:

No, thanks