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 [email protected]. To post to this group, send email to [email protected]. Visit this group at https://groups.google.com/group/h2-database. For more options, visit https://groups.google.com/d/optout.
