Re: Possible bug with MVCC and schema creation.
Fred Toussi <[email protected]>
| Newsgroups | gmane.comp.java.hsqldb.user |
|---|---|
| Message-ID | <1371927877.1836.140661247259557.05897608@webmail.messagingengine.com> |
You have investigated this correctly. This is why you should not use multiple connections from the same thread when using MVCC with an in-process database. There is no plan to change the current behaviour. Fred On Sat, Jun 22, 2013, at 13:09, Nigel Magnay wrote: Hi! I've been diagnosing a couple of instances where our application seems to deadlock when using HSQLDB (but is OK on other databases). I think I now understand a secondary case when using MVCC. I'm using the latest code from SVN. When our app starts up, there is a thread responsible for creating the database (if it doesn't exist). This amounts to the following occuring (I've stripped it out to the calls that aren't relevant ): One connection is created. It then does : conn.setAutoCommit(false); and nothing else. Then a second connection is created (same thread). It attempts to then start executing "CREATE TABLE" functions. However - it deadlocks on the first statement and never returns. If the first connection is not created, everything works fine. This seems to be because of the following: TransactionManagerMVCC::beginActionTPL, line 935 does an 'cs.isCatalogLock()' which is true, since the statement is a DDL statement. It then (lines 942+) finds all the other sessions (which is the other session), and calls setWaitingSessionTPL(session). This ends by calling session.latch.setCount(count); On the current session. Then, later on, line 1319 of Session.java, there is a latch.await() which now waits forever. I obviously don't understand the code enough to be able to determine what's going wrong here. I can re-write things to avoid having the concurrent connection, but I'm fairly sure my other deadlocks are similar situations, which probably means a statement has deemed to require a catalog lock, and there's something blocking it (which may be a totally idle connection in a dbcp connection pool). ----------------------------------------------------------------------- ------- This SF.net email is sponsored by Windows: Build for Windows Store. [1]http://p.sf.net/sfu/windows-dev2dev _______________________________________________ Hsqldb-user mailing list [2][email protected] [3]https://lists.sourceforge.net/lists/listinfo/hsqldb-user References 1. http://p.sf.net/sfu/windows-dev2dev 2. mailto:[email protected] 3. https://lists.sourceforge.net/lists/listinfo/hsqldb-user ------------------------------------------------------------------------------ This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev _______________________________________________ Hsqldb-user mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/hsqldb-user