Category: ZIM Product Suite

This option is not used by Zim Server and might be removed in future releases.

datablock timeout milliseconds

The time milliseconds indicates how long a buffer is going to stay in memory before Zim Server can use it to make additional room for new buffers being read.

When a Zim session make a request to Zim Server to read a particular block of data, depending on the configuration option Blocks Per Read, more than one block can be read and stored in memory buffers, all in the same operation because a physical read operation brings more than one block at a time.

If, sometime later, these additional buffers are required for subsequent operations, these blocks will be found in memory thus saving physical read operations. However, because they can take space from useful blocks, they are marked to expire in the next milliseconds set by this configuration option.

This very same mechanism happens when a transaction is either committed or aborted. In these cases, if a particular buffer is no longer used after the commit or the abort, then the corresponding buffer is also marked to expire as above.

The smaller the number of milliseconds, the faster a buffer can be released from memory in case of need. This is particularly interesting for very active applications or for small number of Maximum Data Blocks.

Valid Settings

Range between 0 to 60.

files per transaction files

This configuration option manages the number of files that a single transaction can handle within its scope. The parameter files actually indicates how many entity sets and relationships with fields can be processed in the same Zim command for implicit transactions or for all commands within the boundaries of a TRANSACTION and ENDTRANSACTION/QUITTRANSACTION commands.

If using roles defined over either an entity set or a relationship with fields, the roles and their corresponding real objects are counted only once.

Valid Settings

Range between 5 to 100.

quick locks locks

To set a lock on a specific block of data, Zim Server resorts to two levels of locking: first, it tries to set a very fast lock held on a small table of locks. This is the quick locks table with the size of locks. Then, if not possible, Zim Server uses secondary locks (refer to Secondary Lock Groups and Secondary Lock Group Size).

A quick lock table is maintained for each lock specified in Maximum Locks and keeps track of which users are responsible for each lock.

Valid Settings

A number from 5 to 100.

scatter table entries nn

Maximum number of entries pointing to lists of blocks currently in use. Each entry corresponds to a block (located in memory) used by a particular user.

Each block is described by the configuration option Scatter Table Links. Every time a user uses a block, a table entry is used. Therefore, if more than one user are using the same block, each user allocates one table entry, but all of them point to the same table link.

The number nn must be greater than the number of Scatter Table Links.

Valid Settings

A number from 50,000 to 30,000,000.

object timeout seconds

This time indicates how long Zim Server has to wait to acquire control over some objects (locks, buffers, etc.) that are not available in memory before deadlocking the current transaction.

The number of seconds is big enough to wait for the object to sleep, go to a pending list if necessary, and then be available for the transaction.

If you want to minimize this delay, set the value to 1. However, this will increase the consumption of CPU because Zim Server needs to check more often the availability of the resources needed. If your application performs well with a lower value (like the suggested of 1), than this should be your choice for this option.

Valid Settings

Range between 0 to 60.

maximum tables files

The number files indicates the maximum number of Zim files that Zim Server can process simultaneously for all databases.

Usually (but not always), a good indication for the maximum files in a particular database is to use the highest Zim file number (that is, ZIM0150, ZIM2010, etc.). In this case, 150 or 2010 can be the maximum files.

As an example, if Zim Server is currently controlling two databases, and one of them has 300 tables and the other one has 500 tables, then this configuration option must specify at least 800 files (a good number would 1000 in this case). By tables, it is meant entity sets and relationships with fields.

Valid Settings

A number from 100 to 32,000.

maximum locks locks

The number of locks is the maximum number of locks that Zim Server can handle simultaneously. This means that the sum of all locks used in all ongoing transactions cannot exceed this number. Consequently, the larger the number of users, the bigger the number of locks needed, and, correspondingly, more shared memory will be required.

The utility ZimAdmin can help to monitor the number of locks actually in use. The initial line of action would be to accept the default number and then, by monitoring the usage of these locks, increase or decrease the value according to real needs.

Valid Settings

A number from 100 to 10,000,000.

maximum data blocks blocks

This is the number of real blocks of data kept in memory at a given time by Zim Server to process transactions.

The bigger the number, the faster transactions will be because more data will be available all the time. Its number depends only on the available shared memory.

If users request more blocks of data in a single transaction than is possible to accommodate in memory, Zim Server saves least used blocks on disk and bring them back if they are again needed.

When a transaction finishes, blocks of data used in this transaction still remain in memory until they are reused or until their space is used by other blocks from other transactions.

Valid Settings

A number from 100 to 10,000,000.

pending timeout cycles

When an object requested by some operation being performed by Zim Server is not available (for instance, locks, blocks, etc.), the request goes to a list of pending objects and stays in the list until the object request can be satisfied.

In this list, the object stays for the number of cycles until either the request is satisfied or the current transaction requesting the object is deadlocked. A cycle is a processing unit within the mechanism that controls the pending objects and it is usually a couple of milliseconds.

If you want to minimize this delay, set the value to a low number. Note, however, that the lower this number, the greater the chance Zim Server would deadlock again because the very small time frame associated to each cycle which might not find the resource available yet.

Valid Settings

Range between 0 to 1000000.

checkpoint transactions nn

This option indicates how many transactions must be committed to the temporay log file before performing a checkpoint that commits ongoing transactions to disk.

The smaller the number of transactions, less efficient will be the overall performance of the system, but the databases involved will be more often updated.

If the number of transactions is big, ZIM Backup Server, if running, will take more time to perform the backup process. Also, depending on the number of buffers updated in each transaction, the temporary log file size can vary significantly.

Regardless of the number of transactions, in case of a disk crash, ZIM server will automatically recover all consistent transactions present in the temporary transaction file.

A checkpoint is triggered whenever the number of checkpoint transactions or the number of checkpoint buffers happens first.

Valid Settings

Range between 1 and 100000.