What is the Journal file for Android

The purpose of a journal ("journal" ) is to ensure the atomicity of the changes made to the database data: let's say you have a transaction with 3 inserts / updates / deletes; how do you ensure that or all three succeed or all three fail? How do you ensure that, for example, you do not subtract funds from a bank account, and before you add those funds to the other, your computer crashes and those funds disappear?

This is done through a special file, which records all the transactions that are being carried out until their completion. An example (fictitious) would be:

iniciou transação
fez insert na tabela X com os valores A
fez insert na tabela Y com os valores B
fez update na tabela Z com os valores C; os valores antigos eram D
commit

When you start the transaction, the bank is in its original state; when you make the first insert , it stores the new data in a temporary region (example, each bank can do this differently); idem pro second; idem pro update ; when you commit, it takes the data from the first insert and places it in the final table; idem pro second and pro update ; once it is done, it clears journal .

Why all this? Simple:

• If the computer crashes before committing, restarting the database reads the journal, sees no commit, and throws away the entire transaction;
• If the computer crashes after the commit, when the database is restarted it reads the journal, sees if each individual transaction has already had its data moved to the final table, and if it does not have it complete;
  • If the computer crashes again while it is doing so, the next time it connects it starts over again ...
  • When it finally finishes the transaction, it only deletes the journal .
• If the computer crashes after a rollback, restarting the database reads the journal, sees if each individual transaction has already been undone (does not apply to our example, where changes are only committed on end, but other strategies may require this), and if it was not he completes the operation;
  • If the computer crashes again while it is doing so ...
  • When finished, delete journal .
• If the computer crashes when the journal is empty / absent, when it reconnects it knows there is no "midstream" transaction, then it can continue to be good.

Note that if there is no journal on file, atomicity of any transactions can not be guaranteed! # the AP asks for a way to disable it (ie to make the journal only exist in memory / does not exist at all). If you do not have a good reason to do this, do not: otherwise, your transactions may be incomplete (unless of course you do not have any complex transactions that require atomicity).

And if I have not been clear, this is true even for "transactions" with a single transaction (I am uncertain about the transactions out of a transaction, but for security I would assume that this is also the case ). Citing the SQLite documentation :

  

Journaling mode MEMORY saves rollbacks journal in volatile RAM. This saves disk I / O but at the expense of database security and integrity. If an application using SQLite crashes in the middle of a transaction when MEMORY mode is active, then the database file is probably corrupted.

     

Journaling mode OFF completely disables rollbacks journal. No diary is created and there is never a file to remove. (...) If an application using SQLite crashes in the middle of a transaction when OFF mode is active, then the database file is probably corrupted.

Additional references:

• This my answer to the question "What is a MySQL Transaction for?"
• This answer to my question "How to implement journaling in Python?"