what does Durability mean actually in DBMS?

Question

From Durability

Once a user issues a commit command, then the transaction is first written to the database files stored on a non-volatile medium such as a hard disk, which is done before confirming to the user that the save has occurred. If a database crashes before the save, the data is still on the transaction logs the next time the database is restarted, but any uncommitted changes are undone or rolled back.

1. Say i start the transaction
2. Fire first insert statement;
3. Fire second insert statement;
4. commit;
5. Transaction Ends

Now when user does commits at step 4,

1. All insert statement are written to transaction logs in file system at Time T1
2. Confirmation is sent to users transaction is commited though it will be done in step 3 at Time T2
3. Now trasanctions are witten asynchronously at Time T3

Is above understanding correct ? If yes ,My question why not confirmation is sent after step 3? Also what if DB machine crashes abefore T2, then transaction will not durable ? So with logs we are just ensuring if DB crashes b/w time T2 and T3 then we can ensure durability

Second understanding I believe all transaction statements may be written in logs as soon as statement is fired instead of doing it at commit time. Once commit is done, transaction logs will be just marked as commit and send the confirmation. Now even DB crashes after confirmation , DB will ensure to write it DB file from transaction logs. So basically instead of writing all transaction statements in one go at commit time, Db is writing statement in logs as and when they fire. At time of commit, it is just marking those transaction as commit and ultimately will be written in db blocks from logs

This question from oracle perspective

Answer 1

Your second understanding is close.

As article you mentioned also says

Durability in modern relational database systems is usually achieved by means of transaction logs- recyclable files - files used to store all database transactions in a session

No when commit is done,

1. First DB vendor, marks the all transactions in that session commit.
2. Then permanently stores those transaction data in DB files.
3. Then send the confirmation to user
4. Now even dB crashes after step 1, DB vendor while startup can read that transaction was committed in logs but complete transaction is not written DB block. So will complete those transactions and rollback uncommitted ones logs

But yes IF DB crashes before step 1 itself, then it won't be persisted even while startup as its not written in transaction logs