# Setting the Transaction Log File Type

> As explained in the Persistent Database I/O page, database log file updates are performed automatically by the eXtremeDB Disk Manager whenever persistent data is written to the database. In the event of a hardware or software failure, the runtime can recover the database using this log. Log file updates clearly do not affect read performance but write performance will be affected because exactly one write to the file system is required for each database transaction.

> The application determines the format of the log file by setting the database open parameter `LogType` to one of the following:

> - `NoLog` – Non-transactional mode; log file updating is disabled
> - `RedoLog` - Standard Write Ahead Logging (WAL), also often referred to as Deferred Modifications Logging with limited transaction size
> - `UndoLog`- Immediate Modifications Logging

> The application must choose this `LogType` when the database and the log files are created and continue using the same `LogType` for the life of the database (except when `NoLog` is specified, see below) because different log file formats are not interchangeable. Also, there are log file parameters specific to the log file type selected.

> Some implementation details for each of these modes are described in the sections below. For further details please see the Persistent Database I/O page. Links to the pages describing the specific native language APIs for setting the log type are provided in the table below.

> ## The Non-transactional Mode (NoLog)

> Note that this mode is UNSAFE. If this option is selected, log file updating is turned off, and a log file is not created. This will significantly increase update performance, but the application will not be able to recover the database in the event of a crash, and transaction rollback is also not available. This mode can be useful when the application needs to quickly populate the database file. But it is not recommended to use this option under any other circumstances.

> Note that once the database file is created, the database can be re-opened in either of the transactional modes described below.

> ## Write Ahead Logging or Deferred Modifications Algorithm (RedoLog) Implementation

> Write Ahead Logging (WAL) is a standard approach to transaction logging. (Please refer to the Persistent Database I/O page for a detailed discussion of the `RedoLog` policy.)

> When the `RedoLog` policy is used all pages modified by a transaction are "pinned" in memory. Therefore, the transaction size is limited by the size of the page pool. Quite often this limitation prevents applications (and xSQL) from performing operations such as creating tables or indexes. The transaction size is effectively limited by the available memory.

> The optimizations discussed here make it possible, in many cases, to allow transactions larger than the pool page size. The basic idea behind these optimizations is that newly allocated pages are written directly to the database file instead of the log file (when necessary). These pages do not break the database consistency because all references to the new pages (such as root pages that contain index headers, bitmap pages) are still kept in memory until the transaction is committed. During the commit, the database file is updated (committed) to the media first. This guarantees that all new pages are preserved on the media. Then the `RedoLog` commit takes its normal course; i.e. the modified pages are written to the log, the log is committed (flushed) and then the modified pages are written to the database.

> There are pros and cons to this optimization: on the plus side, new pages are written to disk only once instead of two times as in the default version of the algorithm (only the database file is updated); on the other hand, the `flush()` has to be called twice as both the database file and the log file must be committed to the media during the transaction commit.

> The use cases that benefit from this optimization include creating new tables and creating new indexes (SQL operations `create table`, `create index`). However when the index is very large the header pages must still be pinned into the cache. Also when large scale modifications are performed (for example, in SQL, updating all records of a large table (`update T set x=x+1`), the optimization does not provide any benefits.

> Internally, this mechanism is always enabled when it is necessary to start replacing pages in the pool; i.e. when new pages are pushed out to the database file unconditionally. In C applications, this optimization is enabled by setting the `mode_mask` flag `MCO_DB_REDO_LOG_OPTIMIZATION`. (It is not enabled by default.)

> (The xSQL `mode_mask` flag can be set through the configuration file. The optimization is turned off by default.)

> ### Log file size control with REDO log mode

> When using `REDO` mode, the log file size is limited with parameter `redo_log_limit`. This is a field of `log_params` structure - part of `dbparams`.

> There is a corresponding `xSQL.cfg` option for this parameter:

>         # Log settings (mco_db_params_t::log_params)
>         log_params: {
>         ...
>             # mco_log_params_t::redo_log_limit, unsigned
>             redo_log_limit : 16m,
>         ...

> The default limit is `16Mb`. The actual file size when it will be truncated is 2 times the `redo_log_limit`, so the default is `32M` of actual disk file size.

> ## Immediate Modifications Logging (UndoLog policy)

> As explained in the Persistent Database I/O page, when the `UndoLog` policyis used, the log file contains entries that allow the current transaction’s updates to be un-done.

> The advantages of using Undo Logging are that the algorithm never runs out of memory and provides easy and efficient recovery. However this policy typically has slower performance than `RedoLog` because, when committing to persistent media, all updates are written to the database file which are usually random access and thus are slower than writes to the log file.

> ## Choosing the Log File Type

> In addition to the guidelines for choosing the proper logging strategy presented in the Persistent Database I/O page, below are further tips to determine the best log file type for a specific application it is helpful to consider the two following general application categories:

> > Type 1: Long Transactions

> > > Long-running transactions

> > > Performance insensitive at commit

> > > Space-constrained transactional environments

> > Type 2: Short Transactions

> > > Short transactions (OLTP systems)

> > > Fast commit—throughput and latency sensitive applications

> Generally Type 1 applications will use `UndoLog` logging, whereas Type 2 applications will use `RedoLog` logging. Though the choice of log file type can impact performance, and `RedoLog` logging will be faster, application performance is more directly affected by the choice of when to flush data to persistent media. This is determined by the Transaction Commit Policy which is explained in the Persistent Database I/O page. First it is important to understand what database transactions are and how they are managed.

> ## Setting the log file type and parameters

> The APIs for setting the log file type and parameters are specific to the programming language used. Please use the links below to view detailed explanations and examples for your development environment:

> C | Setting the log file type and parameters in C
> C++ | Setting the log file type and parameters in C++
> Java | Setting the log file type and parameters in Java
> C# | Setting the log file type and parameters in C#
> Python | Setting the log file type and parameters in Python