And stupidly I forgot the link to the github project. Here it is: https://github.com/dtonhofer/testing_h2_and_spring_jdbc
On Friday, September 1, 2023 at 2:48:44 PM UTC+2 Ronery Coder wrote: > Good day! > > I burned some time to write Java code which tests H2 database transaction > behaviour through Spring Data JDBC. Well documented. Nothing particularly > complex or groundbreaking, just JUnit tests to experiment with. This may be > of interest to people who want to do their own tests. > > This project contains the tests, along with two other subjects, namely an > exercise involving agents who communicate via the H2 database and an > exercise that verifies that Java Instants are indeed properly stored and > retrieved. > > What to report on the exploration of transactions: > > > 1. I have been unable to generate the "Phantom Read" phenomenon in > isolation level ANSI "REPEATABLE READ" . This may be because H2 > preventatively nixes it at that level, where it is supposed to still > occur. > It's possible, depending on how transactions are implemented. Or I just > don't use a predicate that is complex enough. > 2. Trying to elicit "Non-Repeatable Read" and "Phantom Read" phenomena > at isolation level ANSI "READ COMMITTED", we find that the phenomena are > unexpectedly *absent* in ~0.18% of cases, apparently randomly: H2 > implements stronger transactions than expected. I *don't* think it is my > test code that is the reason, but then again, I'm not sure. > 3. There is some problem in Spring Data JDBC "translating" an > `org.h2.jdbc.JdbcSQLTimeoutException`, leading to the user code receiving > a > confusing `org.springframework.transaction.TransactionSystemException` > with > the message `JDBC rollback failed`. This should probably be fixed at the > Spring level. > 4. H2 is quite radical in generating "deadlock exceptions" > (`org.h2.jdbc.JdbcSQLTransactionRollbackException`). As long as two > transaction T1 and T2 were active concurrently, T1 wrote X, then committed > and T2 read or wrote _something_ then (after T1's commit), writes X too, a > deadlock is detected. If I reflect on what could go wrong in such > scenarios, I don't see the reason for throwing. Is H2 just extremely > pessimistic/conservative? > > > > -- 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 view this discussion on the web visit https://groups.google.com/d/msgid/h2-database/060c3410-ccc2-4c36-99cb-bf56b041e223n%40googlegroups.com.
