Svetlin Nakov - Transactions: Case Study

15
Transactions: Transactions: Case Study Case Study Svetlin Nakov Svetlin Nakov National Academy for National Academy for Software Development Software Development academy.devbg.org Transactions at the Supermarket’s Transactions at the Supermarket’s Pay-Desk Pay-Desk

Transcript of Svetlin Nakov - Transactions: Case Study

Page 1: Svetlin Nakov - Transactions: Case Study

Transactions:Transactions:Case StudyCase Study

Svetlin NakovSvetlin NakovNational Academy for Software National Academy for Software DevelopmentDevelopment

academy.devbg.org

Transactions at the Supermarket’s Pay-DeskTransactions at the Supermarket’s Pay-Desk

Page 2: Svetlin Nakov - Transactions: Case Study

Session and Transaction: Session and Transaction: Case StudyCase StudySession and Transaction: Session and Transaction: Case StudyCase Study

• We have a supermarket and we need to We have a supermarket and we need to process ordersprocess orders

• An order is a set of order items (product, An order is a set of order items (product, quantity) entered with a bar-code readerquantity) entered with a bar-code reader

• Processing a set of order items can take Processing a set of order items can take few minutesfew minutes

• We should keep the transactions small to We should keep the transactions small to allow high concurrencyallow high concurrency

• What we can do?What we can do?

• We have a supermarket and we need to We have a supermarket and we need to process ordersprocess orders

• An order is a set of order items (product, An order is a set of order items (product, quantity) entered with a bar-code readerquantity) entered with a bar-code reader

• Processing a set of order items can take Processing a set of order items can take few minutesfew minutes

• We should keep the transactions small to We should keep the transactions small to allow high concurrencyallow high concurrency

• What we can do?What we can do?

Page 3: Svetlin Nakov - Transactions: Case Study

Solution 1Solution 1Add Each Item in Separate TransactionAdd Each Item in Separate Transaction

Page 4: Svetlin Nakov - Transactions: Case Study

Case Study: Solution 1Case Study: Solution 1Case Study: Solution 1Case Study: Solution 1

• Create an order in state Create an order in state active=falseactive=false, , save it and commit the transactionsave it and commit the transaction

• Commit a transaction for each order itemCommit a transaction for each order item

• Persist orders items in the database in Persist orders items in the database in active=falseactive=false state state

• If save of order item fails, rollback the If save of order item fails, rollback the transaction and correct the invalid itemtransaction and correct the invalid item

• Finally start an additional transaction, Finally start an additional transaction, process the payment and commit itprocess the payment and commit it

• Change the order state to Change the order state to active=trueactive=true

• Create an order in state Create an order in state active=falseactive=false, , save it and commit the transactionsave it and commit the transaction

• Commit a transaction for each order itemCommit a transaction for each order item

• Persist orders items in the database in Persist orders items in the database in active=falseactive=false state state

• If save of order item fails, rollback the If save of order item fails, rollback the transaction and correct the invalid itemtransaction and correct the invalid item

• Finally start an additional transaction, Finally start an additional transaction, process the payment and commit itprocess the payment and commit it

• Change the order state to Change the order state to active=trueactive=true

Page 5: Svetlin Nakov - Transactions: Case Study

Case Study: Solution 1Case Study: Solution 1Case Study: Solution 1Case Study: Solution 1

• We have a series of small transactionsWe have a series of small transactions• Don’t keep long transactions in the DBDon’t keep long transactions in the DB

• Works well for Web applicationsWorks well for Web applications

• How to deal with the following:How to deal with the following:• Customer takes the last bottle of vodka Customer takes the last bottle of vodka

but does not checkoutbut does not checkout

• Next customer comes and no vodka is Next customer comes and no vodka is available and goes offavailable and goes off

• The first customer cancel his orderThe first customer cancel his order

• We have 2 customers but have no saleWe have 2 customers but have no sale

• We have a series of small transactionsWe have a series of small transactions• Don’t keep long transactions in the DBDon’t keep long transactions in the DB

• Works well for Web applicationsWorks well for Web applications

• How to deal with the following:How to deal with the following:• Customer takes the last bottle of vodka Customer takes the last bottle of vodka

but does not checkoutbut does not checkout

• Next customer comes and no vodka is Next customer comes and no vodka is available and goes offavailable and goes off

• The first customer cancel his orderThe first customer cancel his order

• We have 2 customers but have no saleWe have 2 customers but have no sale

Page 6: Svetlin Nakov - Transactions: Case Study

Solution 2Solution 2Keep Long TransactionKeep Long Transaction

Perform Critical ChangesPerform Critical Changesin the Last Momentin the Last Moment

Page 7: Svetlin Nakov - Transactions: Case Study

Case Study: Solution 2Case Study: Solution 2Case Study: Solution 2Case Study: Solution 2

• Create an order and keep the transaction Create an order and keep the transaction open during the processing of this orderopen during the processing of this order

• For each order item save it in the For each order item save it in the database and post the changes to DBdatabase and post the changes to DB• If save fails If save fails ccorrect the invalid item and orrect the invalid item and

post it again (transaction is kept open)post it again (transaction is kept open)

• Finally process the payment (update Finally process the payment (update product amounts and cash amounts) product amounts and cash amounts) and commit the transactionand commit the transaction• If something fail, rollback the entire If something fail, rollback the entire

transactiontransaction

• Create an order and keep the transaction Create an order and keep the transaction open during the processing of this orderopen during the processing of this order

• For each order item save it in the For each order item save it in the database and post the changes to DBdatabase and post the changes to DB• If save fails If save fails ccorrect the invalid item and orrect the invalid item and

post it again (transaction is kept open)post it again (transaction is kept open)

• Finally process the payment (update Finally process the payment (update product amounts and cash amounts) product amounts and cash amounts) and commit the transactionand commit the transaction• If something fail, rollback the entire If something fail, rollback the entire

transactiontransaction

Page 8: Svetlin Nakov - Transactions: Case Study

Case Study: Solution 2Case Study: Solution 2Case Study: Solution 2Case Study: Solution 2

• We have only one transactionWe have only one transaction

• We kept it open for a long (few minutes)We kept it open for a long (few minutes)

• We add order items without changing the We add order items without changing the amount of ordered productsamount of ordered products

• Finally we change shared data (cash Finally we change shared data (cash amount and product amounts) just before amount and product amounts) just before commit, when the customer payscommit, when the customer pays

• The transaction is long but the time we The transaction is long but the time we keep locked records in small (few keep locked records in small (few milliseconds)milliseconds)

• We have only one transactionWe have only one transaction

• We kept it open for a long (few minutes)We kept it open for a long (few minutes)

• We add order items without changing the We add order items without changing the amount of ordered productsamount of ordered products

• Finally we change shared data (cash Finally we change shared data (cash amount and product amounts) just before amount and product amounts) just before commit, when the customer payscommit, when the customer pays

• The transaction is long but the time we The transaction is long but the time we keep locked records in small (few keep locked records in small (few milliseconds)milliseconds)

Page 9: Svetlin Nakov - Transactions: Case Study

Case Study: Solution 2Case Study: Solution 2Case Study: Solution 2Case Study: Solution 2

• At the final stage some products can be At the final stage some products can be unavailableunavailable

• We still use optimistic lockingWe still use optimistic locking

• This gives good scalabilityThis gives good scalability

• Good for desktop applications only!Good for desktop applications only!

• When concurrent users are not too muchWhen concurrent users are not too much

• Not applicable for Web scenarioNot applicable for Web scenario

• At the final stage some products can be At the final stage some products can be unavailableunavailable

• We still use optimistic lockingWe still use optimistic locking

• This gives good scalabilityThis gives good scalability

• Good for desktop applications only!Good for desktop applications only!

• When concurrent users are not too muchWhen concurrent users are not too much

• Not applicable for Web scenarioNot applicable for Web scenario

Page 10: Svetlin Nakov - Transactions: Case Study

Solution 3Solution 3Disconnected ModelDisconnected Model

Keep All Changes in the Memory; Small Keep All Changes in the Memory; Small Transaction Commits All of Them at OnceTransaction Commits All of Them at Once

Page 11: Svetlin Nakov - Transactions: Case Study

Case Study: Solution 3Case Study: Solution 3Case Study: Solution 3Case Study: Solution 3

• Don't start any session and transactionDon't start any session and transaction

• Create an order in memory only (in Create an order in memory only (in transient objects)transient objects)

• For each order item create it in memory For each order item create it in memory only (in transient objects)only (in transient objects)

• Immediate data validation is not possible!Immediate data validation is not possible!

• Finally start session and transaction, save Finally start session and transaction, save the order and order itemsthe order and order items,,process the process the payment and commit the transactionpayment and commit the transaction

• If something fail, rollback theIf something fail, rollback the transactiontransaction

• Don't start any session and transactionDon't start any session and transaction

• Create an order in memory only (in Create an order in memory only (in transient objects)transient objects)

• For each order item create it in memory For each order item create it in memory only (in transient objects)only (in transient objects)

• Immediate data validation is not possible!Immediate data validation is not possible!

• Finally start session and transaction, save Finally start session and transaction, save the order and order itemsthe order and order items,,process the process the payment and commit the transactionpayment and commit the transaction

• If something fail, rollback theIf something fail, rollback the transactiontransaction

Page 12: Svetlin Nakov - Transactions: Case Study

Case Study: Solution 3Case Study: Solution 3Case Study: Solution 3Case Study: Solution 3

• Classical “disconnected model”Classical “disconnected model”

• Efficient, optimistic lockingEfficient, optimistic locking

• Hard to implementHard to implement

• If an order item fails to post in the DB, the If an order item fails to post in the DB, the entire order should be canceledentire order should be canceled

• No way to correct one itemNo way to correct one item

• Good for mobile applicationsGood for mobile applications

• Avoid in Web and Desktop scenariosAvoid in Web and Desktop scenarios

• Classical “disconnected model”Classical “disconnected model”

• Efficient, optimistic lockingEfficient, optimistic locking

• Hard to implementHard to implement

• If an order item fails to post in the DB, the If an order item fails to post in the DB, the entire order should be canceledentire order should be canceled

• No way to correct one itemNo way to correct one item

• Good for mobile applicationsGood for mobile applications

• Avoid in Web and Desktop scenariosAvoid in Web and Desktop scenarios

Page 13: Svetlin Nakov - Transactions: Case Study

Solution 4Solution 4Just Pessimistic LockingJust Pessimistic Locking

Page 14: Svetlin Nakov - Transactions: Case Study

Case Study: Solution 4Case Study: Solution 4Case Study: Solution 4Case Study: Solution 4

• Start a transaction with serializable Start a transaction with serializable isolation levelisolation level

• For each order item immediately post For each order item immediately post changes in the databasechanges in the database

• Immediately correct the products Immediately correct the products availability and cash amountavailability and cash amount

• Finally commit the transactionFinally commit the transaction

• Concurrent customers should wait Concurrent customers should wait each othereach other

• No concurrent transactionsNo concurrent transactions

• Start a transaction with serializable Start a transaction with serializable isolation levelisolation level

• For each order item immediately post For each order item immediately post changes in the databasechanges in the database

• Immediately correct the products Immediately correct the products availability and cash amountavailability and cash amount

• Finally commit the transactionFinally commit the transaction

• Concurrent customers should wait Concurrent customers should wait each othereach other

• No concurrent transactionsNo concurrent transactions

Page 15: Svetlin Nakov - Transactions: Case Study

Transactions:Transactions:Case StudyCase StudyTransactions:Transactions:Case StudyCase Study

QuestionsQuestions??