Embedded db: MEMORY vs. CACHED tables and Wifi database cache

Hi,

in my opinion it makes sense to create a CACHED TABLE to store the avatar and maybe also for the MUC log table. Currently all tables are created with “CREATE TABLE” which leads to in-MEMORY tables. After modifying hsqldb.cache_scale the memory footprint may be reduced while the IO operations may increase of course. It may be much better that the operating system caches some data instead that the JVM caches all data.

Wifi database cache[/b]: I did not look at the database cache code, but on page /system-cache.jsp I see that the VCard get’'s cached. Are we using two caches when using the embedded database? Does it make sense to make all tables CACHED ones to disable the HSQLDB memory cache nearly completely?

LG

References:

http://hsqldb.sourceforge.net/web/hsqlFAQ.html

Only if you want to. By default, CREATE TABLE results in a memory table, as this is the best type for smaller tables. For larger tables, use CREATE CACHED TABLE and adjust the hsqldb.cache_scale to suite your memory use requirements

http://hsqldb.sourceforge.net/doc/guide/ch05.html

JDBC Clobs are supported as columns of the type LONGVARCHAR. JDBC Blobs are supported as columns of the type LONGVARBINARY. When large objects (LONGVARCHAR, LONGVARBINARY, OBJECT) are stored with table definitions that contain several normal fields, it is better to use two tables instead.

With CACHED tables, the data is stored on disk and only up to a maximum number of rows are held in memory at any time. The default is up to 3*16384 rows. The hsqldb.cache_scale database property can be set to alter this amount.

http://www.hsqldb.org/doc/guide/ch04.html

describes hsqldb.cache_scale hsqldb.cache_size_scale hsqldb.cache_file_scale …

LG,

Thanks for the improvement request. I filed this as JM-643.

Regards,

Matt