Quantcast

Possible bug with MVCC and schema creation.

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Possible bug with MVCC and schema creation.

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

http://p.sf.net/sfu/windows-dev2dev
_______________________________________________
Hsqldb-user mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/hsqldb-user
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Possible bug with MVCC and schema creation.

Fred Toussi-2
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.
 
_______________________________________________
Hsqldb-user mailing list
 

------------------------------------------------------------------------------
This SF.net email is sponsored by Windows:

Build for Windows Store.

http://p.sf.net/sfu/windows-dev2dev
_______________________________________________
Hsqldb-user mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/hsqldb-user
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Possible bug with MVCC and schema creation.

Fred Toussi-2
In reply to this post by nigelm
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.
 
_______________________________________________
Hsqldb-user mailing list
 

------------------------------------------------------------------------------
This SF.net email is sponsored by Windows:

Build for Windows Store.

http://p.sf.net/sfu/windows-dev2dev
_______________________________________________
Hsqldb-user mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/hsqldb-user
Loading...