On Sat, 7 Jan 2017 16:40:04 +0100 Simone Mosciatti <sisciamir...@yahoo.com> wrote:
> Now it comes a write statement, something like: `INSERT INTO ...` > I push that statement in a buffer and I ack to the client that is > request is been processed. Now it comes another write statement, > `UPDATE ...` I push also that statement into the buffer and I ack the > client. > > Now I decide to write all into disk, so I start a single transaction, > run the insert, run the update, and then commit. > Unfortunately either the INSERT or the UPDATE fails. > The whole transaction is aborted and I should indicate something to > the client. It's clearer to me. I'm not sure it's clearer to you. :-) You're asking a question about application design. The answer will be specific to your application, and can be derived from the two other questions I posed: what is a unit of work, and how many units of works are you prepared to lose? You should never commit less than a unit of work. To maintain data consistency, uncommitted partial transactions are rolled back; that's part of the service provided by the DBMS. The usual transaction-processing advice is to commit each unit of work as a database transaction. That minimizes data loss. Usually, but not always, it maximizes user convenience. If you leave units of work uncommitted, you leave to the user the responsibility/problem of re-creating the information. Depending on the application, that may be trivial, or tedious, or impossible. If re-creating the information is quite cheap, and batching many units of work together in a single database transaction saves significant time, you may choose that as a design option. In terms of what to communicate to your user, ISTM your first obligation is not to lie. The user must be informed when information is "in flight" and when it is committed. He must be able to know the state of the database. In the event of data loss, he must have the wherewithal to re-create any lost information. If you fail to inform the user accurately, or fail to capture information that cannot be re-created, you may expect him to notice, and loudly. --jkl _______________________________________________ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
