1. User request for updating a purchase order/ quotation / Invoice
2. The request is received by the dispatcher
3. Dispatcher keeps the request in queue based on FIFO
4. R/3 Work process handles the request and update the document into temporary tables (cannot update the permanent tables because all the LUW's in the transaction has to be completed)
5. In the process of updating it will communicate with enqueue and obtain the lock on the document so that no other user updates it.
6. The update request goes to the database.
7. Database process handles the request and checks whether table, table definitions and execution (Cost based optimizer) path are valid.
8. All the update requests goes to the database and lock the record in the database so that no user update it.
9. Database process keeps a copy of the record in roll back segment PSAPROLL/ PSAPUNDO table space to roll back in case of CRASH/ System Failure.
10. Gets the record to database buffer for modification (No record is modified in the database directly)
11. As the database buffers need to be accessed by user modifications are not performed in DB Buffers instead in log buffers.
Eg. Consider a pan shop
Customer - Cigarette Paper - Accounts book
Log buffers are a small area around 1Mb - 4 Mb. As the log buffer is small the content is moved in to Redo logs periodically.
Redo logs are duplexed (Mirror logs and Orig Logs) and ensure that the data is updated in the database.
12. The committed data is updated into database
13. The locks are released and rollback gets invalidated.
Note: Committed data can be updated or Redo.
14. User gets the response that the record is updated.