transactions: case study

форум програмиране, форум уеб дизайнкурсове и уроци по програмиране, уеб дизайн – безплатно

програмиране за деца – безплатни курсове и уроцибезплатен SEO курс - оптимизация за търсачки

уроци по уеб дизайн, HTML, CSS, JavaScript, Photoshop

уроци по програмиране и уеб дизайн за ученициASP.NET MVC курс – HTML, SQL, C#, .NET, ASP.NET MVC

безплатен курс "Разработка на софтуер в cloud среда"

BG Coder - онлайн състезателна система - online judge

курсове и уроци по програмиране, книги – безплатно от Наков

безплатен курс "Качествен програмен код"

алго академия – състезателно програмиране, състезания

ASP.NET курс - уеб програмиране, бази данни, C#, .NET, ASP.NETкурсове и уроци по програмиране – Телерик академия

курс мобилни приложения с iPhone, Android, WP7, PhoneGapfree C# book, безплатна книга C#, книга Java, книга C# Дончо Минков - сайт за програмиране

Николай Костов - блог за програмиранеC# курс, програмиране, безплатно

Transactions:Case Study

Transactions at the Supermarket’s Pay-Desk

Svetlin Nakov

Telerik Software Academyhttp://academy.telerik.com

Manager Technical Traininghttp://www.nakov.com

SQL

http://academy.telerik.com/

http://www.nakov.com/

http://forums.academy.telerik.com/

http://kursove-uroci-knigi-obuchenie-programirane-web-design-csharp.info/

http://www.telerik-kids.com/

http://seocourse.telerik.com/

http://html5course.telerik.com/

http://schoolacademy.telerik.com/

http://mvccourse.telerik.com/

http://clouddevcourse.telerik.com/

http://www.bgcoder.com/


http://codecourse.telerik.com/

http://algoacademy.telerik.com/

http://aspnetcourse.telerik.com/


http://mobiledevcourse.telerik.com/

http://www.introprogramming.info/

http://www.minkov.it/

http://www.nikolay.it/

http://csharpfundamentals.telerik.com/













In the Supermarket: Case Study

We have a supermarket and we need to process orders An order is a set of order items

(product + quantity) entered with a bar-code reader

Processing a set of order items can take few minutes

We should keep the transactions small to allow high concurrency

What we can do? 2
































Supermarket: Typical Scenario

1. A customer comes at the pay desk With a full shopping cart

2. The cashier starts processing his order Creates a new order which is

unconfirmed3. The cashier adds each order item

to the order By scanning its bar-code and entering

an amount In case of mistake, the ordered items

can be corrected (added / removed / amount changed)

At this point the order is still unconfirmed (temporary until paid)

3
































Supermarket: Typical Scenario (2)

4. Finally the customer pays The entire order is confirmed The paid amount is added to the

cash amount of the supermarket All ordered items are removed from

the products availability of the supermarket

5. At anytime the order can be canceled This cancels the order and all

ordered items No payment is made Products availability stays

unchanged

4
































Solution 1Add Each Item in a Separate

Transaction































Николай Костов - блог за програмиранеC# курс, програмиране, безплатно Case Study: Solution 1

1. Create an order in state confirmed=false, save it and commit the transaction

2. Add each order item in its own transaction Persist order items in the

database in confirmed=false state If saving order item fails, rollback

the transaction and correct the invalid item

3. Finally start an additional transaction, process the payment and commit it Change the order state to confirmed=true

4. Delete old unconfirmed orders per 1 hour

6
































We have a series of small transactions Don’t keep long transactions in the

DB Works well for Web applications

We have to deal with the following: Customer takes the last bottle of

vodka but does not checkout (it is taken in the DB)

Next customer comes and no vodka is available and goes off

The first customer cancels his order We have 2 customers but have no

sale

7
































Solution 2Keep Long Transaction,

but Perform Critical Changesin the Last Moment
































1. Create an order and keep the transaction open during the processing of the order

2. For each order item save it in the database and post the changes to DB If save fails correct the invalid item

and post it again (this could be complicated)

3. Finally process the payment and commit the transaction Update the product amounts and

cash amounts If something fails, rollback the

transaction

9
































We have only one transaction We keep it open for a long time (few

minutes) We only insert order items without

changing the amounts of ordered products (new data)

Finally (at payment) we change the shared data Update the cash amount and product

amounts Just before commit, when the

customer pays The transaction is long but the time

we keep locked records is small (few milliseconds)

10
































At the final stage (payment) some products can be unavailable We still use optimistic locking This gives good scalability

Works for desktop applications only! When the transaction could be kept

for long When concurrent users are not too

much Not applicable in Web scenarios

11
































Solution 3Disconnected Model:

Keep All Changes in the Memory; Small Transaction Commits All of

Them at Once
































Don't start a transaction or DB session

Create an order in memory only Keep it in transient in-memory objects

For each order item create it in memory only Immediate data validation is not

possible! Integrity constraints cannot be

checked in the DB Finally start session and transaction,

save the order and order items, process the payment and commit the transaction If something fails, rollback the

transaction

13
































Classical “disconnected model” Efficient, optimistic locking Hard to implement If an order item fails to post in the

DB, the entire order should be canceled

Very hard to correct a single incorrect item

Good for mobile applications When the connection is not always

available Avoid in Web and Desktop scenarios

14
































Solution 4Pessimistic Locking
































Start a long-running transaction with serializable isolation level For each order item immediately

post its data in the database Immediately correct the products

availability and cash amount in the supermarket

Finally commit the transaction Concurrent customers should wait each other No concurrent transactions does not

scale Avoid this approach!

16
































?

?? ? ?

??? ?

?

? ?

??

?

?

? ?

Questions?

Transactions: Case Study

http://academy.telerik.com









































transactions: case study

Documents