jspωiki
FLAIM checkpoint

Overview#

FLAIM checkpoint is a Process that brings the on-disk version of the (Typically eDirectory) Data Store to the same coherent state as the in-memory (FLAIM Cache) database.

FLAIM can perform a FLAIM checkpoint during the minimal update activity on the database.

FLAIM checkpoint by default runs every second and writes the dirty cache (FLAIM Cache) to the disk.

FLAIM checkpoint acquires a DIB Lock on the (typically eDirectory) Data Store and performs the maximum amount of possible work until either the FLAIM checkpoint completes or another thread is waiting to update the Data Store.

cpinterval is the time for which the database waits before it initiates the FLAIM checkpoint NDS Thread which brings the on-disk version of the database up to the same coherent state as the in-memory (cache) database. The checkPointThread flushes the Dirty cache to the Disk partition, followed by cleaning up the Roll-Forward Log.

Since FLAIM Block Cache is temporarily suspended while checkPointThread runs, setting the cpinterval to a high value to achieve faster FLAIM Block Cache.

To prevent the on-disk database from becoming too far out of sync, there are conditions under which a FLAIM checkpoint is forced even if other NDS Threads are waiting to update the DataStore:

FLAIM checkpoint Monitoring#

FLAIM checkpoint Monitoring can be performed by using the LOCK parameter within ndstrace which will show the DIB Lock activity.

iMonitor Diagnostic Logger

FLAIM Updates#

Only NDS Threads performing Create, Update or Delete operations are required to obtain the DIB Lock before performing the operation. Threads performing Read operations (SearchRequest, etc.) do NOT require a DIB Lock before performing the operation.

Also as the checkPointThread on each eDirectory FLAIM DataStore is single threaded there can be no concurrent writing operations.

FLAIM checkpoint Runs When#

Category#

eDirectory

More Information#

There might be more information for this subject on one of the following: