One more issue related to locks not beeing released. I'm working on a sort of statement replication application-level algorithm and performing a load test which fails occasionally.
Same behavior observed on 1.3.176, 1.4.191 and current trunk. Case: 1. Single JVM, start 2 TcpServers via Server.createTcpServer(), each has own basedir, h2-cluster-mode not used, MVCC=true, DB_CLOSE_DELAY=-1 2. create table t1 (id varchar(100) primary key, value integer). Insert some rows. 3. In loop perform: 3.1 getConnection to node1 via "jdbc:h2:tcp:...", setAutoCommit(false), "select * from t1 where id = 1 for update", "update t1 set value = value + 1" 3.2 getConnection to node2 via "jdbc:h2:tcp:...", setAutoCommit(false), "select * from t1 where id = 1 for update", "update t1 set value = value + 1" 3.3 Call commit() on connection to node1 3.4 Call commit() on connection to node2 So far - simple enough. I'm performing about 1000+ such loop iterations per second, 2 threads run this same loop to provide concurrent access, so I have 2 connections to each node. Then 4. Stop h2 node1 with tcpServer.stop() to simulate force shutdown (a failure). Remember that both h2 servers run in same JVM, so the process is still running. 5. Loop catches exceptions when connecting to node1, ignores them and only performs operations on node2. 6. Start node1 again with tcpServer.start() within the same JVM 7. Sometimes queries to node1 become stuck awaiting lock release. I've looked at the internals: 1. Thread gets into RegularTable.removeRow and row.isDeleted() returns true, so exception is thrown 2. That "deleted" row has sessionId=4 (for example), while current Session objects open to node1 have higher ids, for example 5 and 6. Ony 2 connections are open, so I guess all other are already closed. 3. Looking at RegularTable.scanIndex.delta show that it contains 2 entries, both are versions of this row we are selecting for update: 1 entry with version=0 is marked as deleted and another one has version=1. Both entries have same session id pointing to some non-existent session 4. Shutting this VM down and opening node1 database with jdbc:h2:file-url shows no locks and select for update doesn't block 5. I was unable to reproduce the issue when starting each h2 server in separate JVM -- You received this message because you are subscribed to the Google Groups "H2 Database" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at https://groups.google.com/group/h2-database. For more options, visit https://groups.google.com/d/optout.
