Re: [h2] Re: DB growing just by reading LOBs

By the time getResultSet() returns a ResultSet object, a transaction is normally completed, and all rows are buffered on the client side. So there is no copy-on-write type logic necessary for normal rows. However Blobs are different. For LOBs we just send the client a kind of pointer in the

Re: [h2] Re: DB growing just by reading LOBs

On Thursday, 7 December 2017 15:13:40 UTC+1, Noel Grandin wrote: > > > Of course. Under most conditions (ie. with setAutoCommit==true), the > transaction is complete and closed before the > ResultSet is even returned to the client. > This is how JDBC works on most databases. > A read-only

Re: [h2] Re: DB growing just by reading LOBs

On 2017/12/07 1:37 PM, Silvio wrote: Does that mean that you allow reading the resultset AFTER the transaction completes? I was assuming the transaction Of course. Under most conditions (ie. with setAutoCommit==true), the transaction is complete and closed before the ResultSet is even

Re: [h2] Re: DB growing just by reading LOBs

On Thursday, 7 December 2017 12:24:10 UTC+1, Noel Grandin wrote: > > > That is doable, but has nasty performance surprises if you, for example, > do SELECT * on a table with a LOB column. If > the LOB is big enough, it gets buffered to disk on the client side, and > your SELECT performance is

Re: [h2] Re: DB growing just by reading LOBs

On 2017/12/07 12:20 PM, Silvio wrote: When all open LOBs are transferred to the client side of the connection when the transaction is closed they can still be read by the application afterwards. The only noticeable difference in behavior would be a potential performance hit and memory

Re: [h2] Re: DB growing just by reading LOBs

On Thursday, 7 December 2017 10:33:36 UTC+1, Noel Grandin wrote: > > > Backwards compatibility is important to us, and the H2 code has worked > this way since I started working on it. > I totally agree backward compatibility is important. That is why I opted for a (connection/database)

Re: [h2] Re: DB growing just by reading LOBs

On 2017/12/07 9:42 AM, Silvio wrote: Why not transfer all LOBs to the client at once during transaction closing when it does such a nonsensical thing as reading them after closing the transaction they where acquired in? Backwards compatibility is important to us, and the H2 code has

Re: [h2] Re: DB growing just by reading LOBs

On Wednesday, 6 December 2017 20:27:52 UTC+1, Noel Grandin wrote: > > Well, there is also the matter of not having enough time - it would be > fairly complex to get all the edge cases right. > > I think we all understand that you have limited time and resources, no argument there. I would just

Re: [h2] Re: DB growing just by reading LOBs

>That is exactly it. We delete the LOBs on session close and/or after a configurable timeout.< > > > >From my testcase's point of view, neither is happening. Regardless of LOB_TIMEOUT set and repeated DB reopens, DB files grow in size as LOBs are read. I understand that technically you might

Re: [h2] Re: DB growing just by reading LOBs

On 6 December 2017 at 21:13, wburzyns wrote: > Noel, can you elaborate a bit why reading LOBs results in writes to the > database? Is it because the LOB content is copied somewhere in the DB so > that the client does not need to keep transaction open to access LOB > content?

Re: [h2] Re: DB growing just by reading LOBs

Noel, can you elaborate a bit why reading LOBs results in writes to the database? Is it because the LOB content is copied somewhere in the DB so that the client does not need to keep transaction open to access LOB content? If that's the reason then I don't see how the ballooning could be

Re: [h2] Re: DB growing just by reading LOBs

Plase make that a setting. Let's not all suffer for some scarse edge cases -- 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

Re: [h2] Re: DB growing just by reading LOBs

please log this in our issue tracker along with your test case, because it's not something I can fix in the near future. My preliminary analyis is that there is no leak in our LOB management (unlike the first bug you reported). We just don't seem to be doing a very good job of compacting here,

[h2] Re: DB growing just by reading LOBs

Here are conclusions after testing different combinations of backing engines and datatypes: 1) MVStore in master/HEAD is better than in version 1.4.196. 2) The only viable solution, when in comes to storing binary data in H2 is MVStore and BINARY data type - if one can go without streaming. If