磁盘I/O也能够让程序不正确

       HSQLDB数据库执行SHUTDOWN命令，如果系统磁盘I/O性能不是很好的话，也能够造成程序的错误。
      
       该BUG是因为HSQLDB 数据库执行ShutDown命令之后，由于客户端正在运行BT, Emule这样的程序，使得客户端的磁盘一直都处于I/O状态。因此，在程序调用shutdown命令之后，文件系统并没有在非常短的时间内完成文件操作。

       因此，在程序执行到后面，需要对已经生成的文件进行访问的时候，出现了错误。而出现的错误也是比较怪异。一会儿出现文件不存在；一会儿又出现有其他的进程正在对文件进行访问；一会儿还出现客户端无法加载CLASSES；有些时候又可以正常了。

       通过分析，我断定是因为程序在调用shutdown的时候，文件系统执行shutdown较慢的缘故。
        出现文件不存在，是说：在程序执行的哪一点，hsqldb还没有执行完shutdown命令，也就是说在文件系统中还根本没有这个文件；
        有其他的进程正在访问，也就是说，程序在执行的哪一点，还有HSQLDB的Connection还连接在数据库上，可见数据库要执行shutdown命令还是相当耗时的；
        另外，客户端无法加载Classes，因为我们的applet需要访问的classes都是通过jar文件传输过去的，出现这个问题，明显是由于系统I/O比较异常，系统无法在要求的时间加载到APPLET所需要的JAR包。
      
       可见，程序确实还不是很Strong。我以前还从来没有遇到这个问题。

        判定到这个问题之后，我肯定这个错误在于客户端的磁盘I/O系统。因此，我调查了一些客户端测试的环境。原来，客户端的机器一直都在使用emule和bt软件，这两个软件对系统磁盘I/O的性能影响还是比较大。将客户端的bt和emule关掉之后，发现程序正常:)

       可见，磁盘的I/O也能够让程序运行不正确，不要以为调用了statment.execute("shutdown"); 文件系统中立马就会有hsqldb的.script文件了:)这个是不成立的。另外，我们在调用statment.execute("shutdown")之后，系统并不会等到文件操作完成，该语句才返回。从这个道理来讲，程序和文件系统不是同步的，而是消息的。程序给文件系统发送命令，文件系统响应，返回。但是，文件真正存储到磁盘中，可不是程序可以预知的。

       为了增强程序的健壮性，只好在程序执行的下一点，先Thread.sleep(1000)，然后去判断文件是否存在。如果文件不存在，那么报错。

       但是，有多少机会，文件I/O操作是在1s之内完成的呢？只要客户端系统不使用耗I/O的程序，应该都是没有问题的。如果使用了，那多半还是会有问题。不过，sleep 1s也就算了。

这个命令有一个时间片，如果超出这个时间的话，就报异常？

这个命令没有时间片吧。不报异常。如果数据库执行命令，肯定会报SQLException。
这里的问题是数据库执行了shutdown命令，但真正shutdown完却发了很长时间。程序不会等到文件系统把文件I/O操作完才返回。

写I/O 相关 处理等待、超时这种问题比较多。

我也奇怪呢，如果是有时间范围，报异常的话，那也应该是SQLException。 看来应该是I／O一直占用着，造成了一些不确定错误。

我也正愁苦呢，没有很好的解决方案。我上面的给出的方法只是简单的再等一段时间，万一在这段时间内不完成的话，还是会出现错误。

有没有更好的解决方案？

不知道用嵌入模式运行, 不用SHUTDOWN, 而是用 SCRIPT TO 如何. 感觉SCRIPT TO 也许会等执行完了再返回.

不是很清楚你说的嵌入模式是什么，看了SCRIPT的说明，不知道是否会，感觉也不太会等待执行完了才返回。

好像是叫 In-Memory 模式还是什么来的, 就是运行时不写任何磁盘文件, 进程关闭数据就没了那种.
这样就在原本 SHUTDOWN 的地方 SCRIPT 一下, 下次启动的时候再从保存的文件恢复. 不过我也没这么做过, 只是一个想法.