Hello, @Evgenij:
> This code throws OOME unless restore point creation is commented out: I've taken a look at it and at first I thought it's the concurrent system session that commits the auto generated sequence value. However, a bit of playing and testing revealed that I can reproduce at least a similar issue in "vanilla" H2 (i.e. without restore points). It is caused by auto-commit `false` which I tried, because I thought it would prevent database version increments. After all, with a restore point, all commits (database versions) are being retained and thus cost storage. Please find a reproducer at https://github.com/i-am-not-giving-my-name-to-a-machine/h2-tests > This code throws General Error: Very interesting. This shows a blatant shortcoming of my implementation. The oldest version to keep is currently not part of the MVStore *file* (it's only part of the META table of the database), but it has to be to be taken into account in situations where the files are being compacted. This is something I'd happily try to address if this feature has a future. @Andrei > Here is my quick and dirty simulation of the "restore point" with copying of in-memory files: I didn't fully realize that H2 comes with its own in-memory file system. Albeit a very basic one. I have taken your code and tried it for Spring tests. It works great. If anyone is interested, here's my "PoC": https://github.com/i-am-not-giving-my-name-to-a-machine/spring-test-database-restoration-poc This also made me realize that it would be nice if a restore point feature would not drop connections on a `restore to point` SQL execution. If no transaction is ongoing, it could "freeze" the database (block new transactions), restore the database and unfreeze it. That would remove the need for clearing a connection pool of connections to a database that doesn't exist anymore. And a golden copy (nice choice of words btw) wouldn't be necessary as well. @Noel > [...] thanks to H2's excellent internal architecture Couldn't agree more. It was extremely easy to understand the mechanics and interactions. The one thing that "frightens" me the most is the actual storage format/structure of the MVStore, but it's probably not a that difficult either. To wrap up: I'm here, if you want to continue this journey. Maybe you could point me in the right direction where to put the oldest version to keep in the MVStore file. I'm assuming there are some headers and I could simply put it there? Regards, Enno On Monday, November 11, 2024 at 7:38:43 AM UTC+1 Noel Grandin wrote: > Hi > > On 11/9/2024 4:47 AM, Andrei Tokar wrote: > > Forgive me for a possibly stupid question, but why this feature is so > badly needed? > > What's wrong with populating database to a desired state, shutting down, > copying the file, and starting H2 with a file copy. > > Why do you need this functionality for in-memory (non-persistent) > database? If performance is the reason, you can use > > RAM-based file system instead. > > Just noting that in the time I have been working on H2, this is the third > time this feature has come up. > > Some people want to (a) have their test database at a known point (b) run > a _lot_ of unit tests and (c) have their unit > tests run relatively quickly. > > So for all it's shortcomings, I think it would be a useful addition (Plus > I am tickled pink that such afeature could be > implemented in so few lines of code, thanks to H2's excellent internal > architecture) > > Regards, Noel Grandin > -- 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 h2-database+unsubscr...@googlegroups.com. To view this discussion visit https://groups.google.com/d/msgid/h2-database/cc7ffa5b-2513-4ff8-8274-9a7b87631bb5n%40googlegroups.com.
