2

I am using hibernate, and innodb and mysql. I have a pessimistic lock (on a specific table row) obtained at the beginning of a very long hibernate transaction. On occasion, when I run the program that starts this transaction and am running in eclipse in standalone application mode, and do a hard stop of the application (which forces a threaddeath), I have the following scenario:

MySQL does not realize that the transaction was aborted. The next time I run my application, the function which obtains the pessimistic lock (at the beginning of that long transaction) blocks, even though MySQL should realize that that row is unlocked.

The only way to get things working again is to stop the MySQL daemon and restart it, after which the pessimistic lock is obtained.

This really concerns me. This means that any VM exit other than by exception or clean shutdown can leave MySQL in a broken state that requires restarting MySQL daemon. An e.g. is using the normal way to shutdown and restart Tomcat, which in my understanding involves a threaddeath, just like using eclipse to abort a running application.

Have other people encountered this problem? Is there a clean way to stop tomcat which does not involve threaddeath? Shouldn't MySQL be immune to threaddeath in the middle of a transaction that has obtained a pessimistic lock (select for update)?

I am stopping tomcat with $CATALINA_HOME/bin/shutdown.sh

Andy

Andy Nuss
  • 745
  • 1
  • 7
  • 20
  • Did you figure this out? Is there a way to identify the problem row and manually unlock it? (I think we may be seeing a similar problem) – chrishomer Feb 28 '11 at 22:25
  • No, I've seen it 3 times in testing. Haven't figured it out yet. Factors: (1) I'm using Lucene in the same process and when this happens, Lucene gets a fatal corrupted mutex as well. (2) It seems to happen when I'm using mysql client in another process to query the database while my application is running. – Andy Nuss Mar 05 '11 at 15:47
  • I know this is an old question but did you figure out this yet? I think i have a similar problem and could not fix it. – xycf7 Mar 07 '12 at 18:23
  • I came to the opinion that it was a matter of running lucene and mysql in the same process (not a good idea). I would also have lucene locks corrupted too. Since moving lucene to another process, using sockets, I haven't seen the problem. – Andy Nuss Mar 08 '12 at 19:20

1 Answers1

0

MySQL does not realize that the transaction was aborted.

I'd say that you didn't wait enough to trigger the transaction timeout. In any database (and MySQL, for certain), you can specify a transaction timeout which will rollback the transaction if it's not committed before then.

jpkroehling
  • 13,881
  • 1
  • 37
  • 39