The dmf_write_behind option, which is a DBMS Cache parameter, allocates server threads that asynchronously write modified data pages to disk. The write behind threads are controlled by the dmf_wb_start and dmf_wb_end thresholds (both derived DBMS Cache parameters) that were defined at server startup time.

The write behind threads (dmf_write_behind) can be either ON or OFF for each defined cache (2k, 4k, and so on). The default is ON. A primary write behind thread is on for the life of the server. Additional threads are spawned to assist with the flushing of the cache, if necessary. When the flush is complete, these temporary threads are terminated.

The dmf_wb_start and dmf_wb_end thresholds (derived DBMS Cache parameters) can be individually overridden for each cache, but doing so is typically not necessary.

By allowing transactions to commit without waiting for data to be flushed to disk, fast commit can significantly improve response time. However, the data page caches of fast commit servers tend to become filled with modified pages. The write behind threads control the number of modified pages by asynchronously writing them to disk.

If write behind threads are not used, a server quickly reaches its modified page limit (specified by dmf_modify_limit). When that happens, transactions begin to do synchronous writes to free up space in the cache, negating some of the benefits of using fast commit. For this reason, if you configure a server with fast commit, dmf_write_behind must be ON to get the full performance benefits of fast commit.

For two sessions to have concurrent access to a database using fast commit, each session must access the database through the same DBMS Server or through servers connected to a common buffer. To be connected to a common buffer, the server must use the cache_sharing parameter. When a server configured with the fast_commit option opens a database, it locks the database so that no other server (except a server using the same buffer cache) can access the database.