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 resultset that does not use a server-side cursor would allow closing the transaction and then returning the resultset as a whole (which I understood is what H2 does since it has no cursor support). If a resultset is updatable I am not sure (since I never use those). But I expected such a resultset to hold the transaction because of staleness issues when updating after the transaction is closed. Then again, I have little experience with updatable resultsets. > > So most people tend to call getBlob() and expect it to work, even though > they are now fetching data outside a transaction. > > And they expect it to work even if something else deletes the LOB while > they are reading it - outside the transaction :-( > > So fixing this requires some work, and requires a fair amount of care on > the part of people writing code to read LOBs > from H2. > If my premise of a transaction being open while the resultset is read does not hold then I see various issues arise. But then the problem also exists for possibly updated non-BLOB values. I expect this to be solved by the MV-part of the MV-Store, suspecting some copy-on-write logic. Why are BLOBs different then and not allow copy-on-write? I am just asking because I am interested in how this thing works. Feel free to not feel like elaborating. -- 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 post to this group, send email to h2-database@googlegroups.com. Visit this group at https://groups.google.com/group/h2-database. For more options, visit https://groups.google.com/d/optout.
