Transactions and lock states form a part of the makeup of the API and its functions.
Although difficult to control in their entirety, locks and transactions are interlinked with queries within SQLite and most database systems. The key to better transactions involves the programmer writing good SQL code, ensuring that it will perform well, and catering for possible errors and issues during the journey so that the application does not crash or leave the user in the lurch. Another issue with locks will relate to which resources you need. Sometimes, it could be a badly written code that does not use autocommit or is holding an exclusive lock to a table and another part of your process, and you can't update it, as an example. So, it is very important for the programmer to gauge, learn the API, and understand how locking and transaction strategies will work to produce a smooth and good app.
By default, autocommit is used in SQLite where transactions cycles start and end, which are controlled by programmers and statements used for the app. Each SQL command will run in its own transaction since autocommit is used. However, within a transaction, especially using a begin command, the programmer has to manually call a rollback, or a commit to update the database. Sometimes, a locking strategy such as this may cause SQL violations or errors, which has to be handled by the error handling code within the app.
In terms of passwords, as a programmer or designer, do not store password, such as database passwords, in any clear text or script that may be accessed by any user. For example, in a directory to a web server, a source file can be compromised.
Application authentication should be done on two levels with heavy type password formats so that access is not compromised, especially with technology, such as spyware that looks into compromising your system. The data can be encrypted when database authorization provisions do not offer sufficient protection, which is initially required.