HSQLDB SET FILES CACHE ROWS/SIZE和SET FILES WRITE DELAY似乎沒有按預期的那樣工作

Question

我正在使用嵌入式HSQLDB。 的操作系統是Windows 7

這裏是SET FILES特性，其顯示在腳本文件：

SET FILES WRITE DELAY 500 MILLIS 
SET FILES BACKUP INCREMENT TRUE 
SET FILES CACHE SIZE 10000 
SET FILES CACHE ROWS 50000 
SET FILES SCALE 32 
SET FILES LOB SCALE 32 
SET FILES DEFRAG 0 
SET FILES NIO TRUE 
SET FILES NIO SIZE 256 
SET FILES LOG FALSE 
SET FILES LOG SIZE 50 

從中我明白，數據應該被寫入到磁盤每500ms。另一方面，它應該緩存在內存中，直到10MB或50,000行都在緩存中。

當我後約一分鐘，6000條記錄查看數據庫的目錄，我可以看到這一點：

d:\tmp\test\hsqldb\Run_0>dir 
Le volume dans le lecteur D s’appelle DATA 
Le numéro de série du volume est 3C08-FEE7 

Répertoire de d:\tmp\test\hsqldb\Run_0 

06/04/2013 07:10 <REP>   . 
06/04/2013 07:10 <REP>   .. 
06/04/2013 07:10    32 data.data 
06/04/2013 07:10     0 data.lck 
06/04/2013 07:10     0 data.lobs 
06/04/2013 07:10     0 data.log 
06/04/2013 07:10    89 data.properties 
06/04/2013 07:10    1,757 data.script 
06/04/2013 07:10 <REP>   data.tmp 
       6 fichier(s)   1,878 octets 
       3 Rép(s) 73,975,611,392 octets libres 

d:\tmp\test\hsqldb\Run_0> 

請注意大小。

因此，我推斷SET FILES WRITE DELAY被SET FILES CACHE屬性覆蓋。

我正確嗎？如果在500 ms結束之前高速緩存溢出會發生什麼情況？它會被刷新還是會延遲500毫秒？

編輯

這是奇怪的。我在50個不同的HSQLDB嵌入式數據庫之間分發數據（使用50個不同的數據源對象）。 每個DB有三個CACHED表：

CREATE TABLE RUNSTATS 
(
    ID  BINARY(16) NOT NULL, 
    ENTITY BLOB(128K)  NOT NULL 
    ,CHECK (PUBLIC.RUNSTATS.ID IS NOT NULL) 
    ,CHECK (PUBLIC.RUNSTATS.ENTITY IS NOT NULL) 
); 

ALTER TABLE RUNSTATS 
    ADD CONSTRAINT pk_runstats 
    PRIMARY KEY (ID); 

CREATE TABLE RUNSTATS__AVGLATENCYINDEX 
(
    ID   BINARY(16), 
    TIMESTAMP BIGINT, 
    FLOWID  VARCHAR(200), 
    AVGLATENCY DOUBLE 
); 

ALTER TABLE RUNSTATS__AVGLATENCYINDEX 
    ADD CONSTRAINT pk_runstats__avglatencyindex 
    PRIMARY KEY (ID, FLOWID); 

CREATE INDEX IDX_RUNSTATS__AVGLATENCYINDEX_FLOWID 
    ON RUNSTATS__AVGLATENCYINDEX (FLOWID ASC); 

CREATE TABLE RUNSTATS__CLIENTGWTOTALININDEX 
(
    ID   BINARY(16), 
    TIMESTAMP BIGINT, 
    FLOWID  VARCHAR(200), 
    CLIENTGWTOTALIN DOUBLE 
); 

ALTER TABLE RUNSTATS__CLIENTGWTOTALININDEX 
    ADD CONSTRAINT pk_runstats__clientgwtotalinindex 
    PRIMARY KEY (ID, FLOWID); 

CREATE INDEX IDX_RUNSTATS__CLIENTGWTOTALININDEX_FLOWID 
    ON RUNSTATS__CLIENTGWTOTALININDEX (FLOWID ASC); 

截至目前每個數據庫已收到26000個RUNSTATS對象（約每1K）52,000 RUNSTATS_ AVGLATENCYINDEX和52000個RUNSTATS _CLIENTGWTOTALININDEX對象。

下面是一個任意的DB實例的DIR出的50：

d:\tmp\test\hsqldb\Run_12>dir 
Le volume dans le lecteur D s’appelle DATA 
Le numéro de série du volume est 3C08-FEE7 

Répertoire de d:\tmp\test\hsqldb\Run_12 

06/04/2013 07:10 <REP>   . 
06/04/2013 07:10 <REP>   .. 
06/04/2013 08:25   8,388,608 data.data 
06/04/2013 07:10     0 data.lck 
06/04/2013 07:10     0 data.lobs 
06/04/2013 07:10     0 data.log 
06/04/2013 07:10    89 data.properties 
06/04/2013 07:10    1,757 data.script 
06/04/2013 07:10 <REP>   data.tmp 
       6 fichier(s)  8,390,454 octets 
       3 Rép(s) 33,617,223,680 octets libres 

d:\tmp\test\hsqldb\Run_12> 

的java程序的RAM已發展到超過3GB。

RUNSTATS對象應該去lobs文件，不是嗎？那麼爲什麼這個文件報告爲空？如果一個RUNSTATS對象大約需要1K，那麼在10,000個對象之後達到10000K的限制，但是已經插入了超過26,000個！

請向我解釋這種奇怪的行爲。

Answer 1

您在操作過程中對目錄的讀取可能不會顯示真實的文件大小。這些尺寸在關機後正確顯示。

RUNSTATS blob轉到lobs文件。行在數據文件中。每個Blob將在lobs文件中佔用32K（SET LOB SCALE 32）和128K之間。

WRITE DELAY設置僅與日誌文件相關。它不適用於緩存和數據文件。

在Windows中，您可以使用資源管理器在右擊它之後查看文件屬性。這應該在操作過程中顯示當前的文件大小。