Hi, Thanks a lot! You are right about the problem. I have added a test case and increased the size of the map on the server side. It's not idea. An ideal solution would be stateless. The reason why there is state is security: if the client could send the lob id to the server, then the server would have to check the access rights, and this is currently not possible. So I guess a map is the only viable solution currently. But the size of this map needs to be larger of course. I will use SysProperties. SERVER_RESULT_SET_FETCH_SIZE * 2 currently (until we find a better solution).
One solution might be to use the (cryptographically secure) hash as the id of the blob. But that would require quite many changes. Regards, Thomas On Tuesday, March 27, 2012, Ron Aaronson wrote: > I believe I understand the the cause of the hang. I investigated the > simplest case of using a h2.serverResultSetFetchSize value of 600, > which is greater than the 523 rows I know that I have. As I mentioned, > I can retrieve the first 3 rows (single CLOB column) okay and then I > either hang on the retrieval of the 4th row or I get a "The object is > already closed" exception. > > It turns out that the actual string comprising the first three columns > seem to be rather short in length and method getInputStream in class > org.h2.value.ValueLobDb has the data already and simply returns a > ByteArrayInputStream constructed on this data. The 4th row's data is > still on the server side and so an actual RemoteInputStream has to be > built to process fetch the data from the server-side LOB. > > Here's what seems to be the problem: Class > org.h2.server.TcpServerThread is caching these LOBs in in instance of > a SmallLRUCache. This cache seems to be designed to maintain only the > least recently referenced LOBs!!! The default size of this cache is > given by system property h2.serverCachedObjects, which defaults to 64, > whereas the default fetch size is 100. So even if I had not overridden > the default h2.serverResultSetFetchSize property, if all of my rows > had sufficiently large columns requiring cached LOBs, any fetch size > > 64 would cause the LOB representing the first row to be flushed out of > the cache and I would not even be able to retrieve the first row. > > An LRU cache seems to be the wrong structure for holding LOBs that are > in an active result set. Certainly having a default cache size that is > less than the default fetch size seems less than ideal. > > > On Mar 19, 8:56 pm, Ron Aaronson <ro...@optonline.net> wrote: > > I am retrieving one text column (CLOB) from a table in a "remote" H2 > > database (actually on a local drive, but using Server, i.e. tcp/ip, to > > access it) and after retrieving the first 100 rows the program hangs > > on retrieving the next row of the result set. If, on the other hand, I > > access the same database as an embedded database, there is no problem. > > If I try to display the table's rows using H2's console application > > accessing the database using the Server method, then I get the > > following error message: > > > > IO Exception: "java.io.IOException: org.h2.message.DbException: The > > object is already closed [90007-164]"; > > "lob: null table: 14 id: 1" [90031-164] 90031/90031 > > > > The table has 523 rows. When I started the application specifying > > system property h2.serverResultSetFetchSize with a value of 600, it > > hung after retrieving just 3 rows! When I reran specifying this > > property with a value of 1, it no longer hung! Values up to 87 seem to > > work OK. A value of 88 hung after 88 rows were returned. I am a > > newbie and it's not clear what this parameter is really supposed to be > > doing. > > -- > You received this message because you are subscribed to the Google Groups > "H2 Database" group. > To post to this group, send email to h2-database@googlegroups.com. > To unsubscribe from this group, send email to > h2-database+unsubscr...@googlegroups.com. > For more options, visit this group at > http://groups.google.com/group/h2-database?hl=en. > > -- You received this message because you are subscribed to the Google Groups "H2 Database" group. To post to this group, send email to h2-database@googlegroups.com. To unsubscribe from this group, send email to h2-database+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/h2-database?hl=en.
