Peter Winckles

Default UUID values corrupt script file

Thanks, Fred! I appreciate your work and I hadn't realized that you'd made changes to attempt to address the issue. I'll upgrade.

MVCC deadlock

@fredt I don't know why session 198 is waiting on its latch. Is there something I can extract out of the heap dump that would answer the question? The query it was executing was an insert statement. It was the one and only query in the transaction, and the transaction is committed immediately after the query completes. I do not see an entry in the db log file that corresponds to the insert query. Looking at the latch in the dump, 198's latch sync state is a 0, which means that it should have woken...

@fredt Right, but the problem is that Session 198 is hung. That's the stack trace I included. For some reason, it's waiting on a latch, though my interpretation of the system_sessions data is that it should not be.

@fredt I'm back with a different MVCC CHECKPOINT related deadlock. We are running HSQLDB 2.7.1 on Java 21.0.2 with MVCC enabled. I'm seeing the following in the db: SELECT this_waiting_for, count(*) FROM INFORMATION_SCHEMA.SYSTEM_SESSIONS group by this_waiting_for; THIS_WAITING_FOR C2 ---------------- -- 195 50 198 1 2 select SESSION_ID, THIS_WAITING_FOR, CURRENT_STATEMENT from INFORMATION_SCHEMA.SYSTEM_SESSIONS where this_waiting_for = '198'; SESSION_ID THIS_WAITING_FOR CURRENT_STATEMENT ----------...

@fredt, I figured it out. I was able to analyze the heap dump in VisualVM to identify the HSQLDB session with id 20, and then worked backwards to identify the thread it was associated to. It was an application bug. The bug was that the constructor of a Hibernate entity was calling some really old code that was making a subsequent db query without reusing the connection already associated to the thread. So, when a CHECKPOINT was requested between the two queries, it deadlocked because Hibernate can't...

@fredt, I figured it out. I was able to analyze the heap dump in VisualVM to identify the HSQLDB session with id 20, and then worked backwards to identify the thread it was associated to. It was an application bug. The bug was that the constructor of a Hibernate entity was calling some really old code that was making a subsequent db query without reusing the connection already associated to the thread. So, when a CHECKPOINT was requested between the two queries, it deadlocked because Hibernate can't...