我从“远程”H2数据库中的表中检索一个文本列(CLOB)(实际上在本地驱动器上,但使用tcp访问它),并在检索前100行后,程序挂起检索下一个结果集的行。另一方面,如果我访问与嵌入式数据库相同的数据库,则没有问题。如果我尝试使用H2的控制台应用程序使用服务器(即tcp)方法访问数据库来显示表的行,那么我收到以下错误消息:
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
这是程序。如果我取消注释设置系统属性的调用,程序将起作用。我还尝试使用字符流检索列,或者只是调用getString,由常量USE_STREAM控制。结果没有区别:
import java.sql.*;
import java.util.*;
import java.io.*;
public class Jdbc4
{
private static final boolean USE_STREAM = false;
public static void main(String[] args) throws Exception
{
//System.setProperty("h2.serverResultSetFetchSize", "50");
Connection conn = null;
try {
Class.forName("org.h2.Driver").newInstance();
conn = DriverManager.getConnection("jdbc:h2:tcp://localhost/file:C:/h2/db/test/test;IFEXISTS=TRUE", "sa", "");
Statement stmt = conn.createStatement();
String sql = "select select_variables from ipm_queues";
ResultSet rs = stmt.executeQuery(sql);
int count = 0;
while (rs.next()) {
++count;
String s;
if (USE_STREAM) {
Clob clob = rs.getClob(1);
Reader rdr = clob.getCharacterStream();
char[] cbuf = new char[1024];
StringBuffer sb = new StringBuffer();
int len;
while ((len = rdr.read(cbuf, 0, cbuf.length)) != -1)
sb.append(cbuf, 0, len);
rdr.close();
s = sb.toString();
clob.free();
}
else
s = rs.getString(1);
System.out.println(count + ": " + s);
}
}
finally {
if (conn != null)
conn.close();
}
}
}
这是用于创建表的DDL(您可以看到它最初是一个MySql表):
CREATE TABLE `ipm_queues` (
`oid` bigint NOT NULL,
`queue_id` varchar(256) NOT NULL,
`store_id` bigint NOT NULL,
`creation_time` datetime NOT NULL,
`status` bigint NOT NULL,
`deleted` bigint NOT NULL,
`last_mod_time` datetime NOT NULL,
`queue_name` varchar(128),
`select_variables` text,
`where_clause` text,
`from_table` varchar(128),
`order_by` varchar(256),
`from_associate_table` varchar(256),
`from_view` varchar(128)
);
ALTER TABLE ipm_queues
ADD CONSTRAINT ipm_queues_pkey PRIMARY KEY (oid);
CREATE UNIQUE INDEX ipm_queues_key_idx ON ipm_queues(queue_id, store_id);
CREATE INDEX ipm_queues_str_idx ON ipm_queues(store_id);
答案 0 :(得分:3)
我相信我理解挂起的原因。我调查了最简单的使用h2.serverResultSetFetchSize值为600的情况,该值大于我所知道的523行。正如我所提到的,我可以检索前3行(单个CLOB列),然后我要么继续检索第4行,要么得到“对象已经关闭”的异常。
事实证明,包含前三列的实际字符串的长度似乎相当短,而类org.h2.value.ValueLobDb中的方法getInputStream已经具有数据,并且只返回在此数据上构造的ByteArrayInputStream。第4行的数据仍然在服务器端,因此必须构建实际的RemoteInputStream来处理从服务器端LOB获取数据。
这似乎是问题:类org.h2.server.TcpServerThread在SmallLRUCache的实例中缓存这些LOB。这个缓存似乎只是为了维护最近最少引用的LOB!此高速缓存的默认大小由系统属性h2.serverCachedObjects提供,默认为64,而默认提取大小为100.因此,即使我没有覆盖默认的h2.serverResultSetFetchSize属性,如果我的所有行都足够大需要缓存LOB的列,任何提取大小> 64会导致代表第一行的LOB从缓存中刷出,我甚至无法检索第一行。
LRU缓存似乎是用于保存活动结果集中的LOB的错误结构。当然,默认缓存大小小于默认提取大小似乎不太理想。
答案 1 :(得分:0)
您应该提供更多详细信息,但是您检查了网络连接吗?也许您的数据库服务器在尝试获取太多数据时就会阻止连接(或网络连接)。这可能是一种“某种”保护。