Re: Possible bug with MVCC and schema creation.

Just to add some information to my previous reply.

You should be looking at what your other session is actually doing. As
you said "(lines 942+) finds all the other sessions (which is the other
session)", but I must correct it as "finds all the other sessions that
are in a transaction" which does not include a session on which a
session-scope statement such ast SET AUTOCOMMIT has been executed.

I hope this helps you find the actual cause of the deadlock which is
probably another session which has previously performed a DDL or DQL
statement using the same or another thread  and has not committed.

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