Hi,

I've put some more work into this feature request and wanted to end this 
thread here in favor of a PR 
<https://github.com/h2database/h2database/pull/4169> I've just created on 
GitHub. In case anyone is interested.

Regards,
Enno

On Monday, November 11, 2024 at 11:07:04 PM UTC+1 Enno Thieleke wrote:

> 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 [email protected].
To view this discussion visit 
https://groups.google.com/d/msgid/h2-database/0ad05d26-bd75-448d-b7b5-c680a705bfcen%40googlegroups.com.

Reply via email to