The primary tool for handling concurrency in business applications is the transaction. Examples:

• ordering an item(s) on Amazon
• getting cash from an ATM
• purchasing coffee using your Starbucks app
• buying an IPA at the Warren Guild.

Characterics of a Transaction

1. A transaction is a bounded sequence of work with a defined beginning and ending (i.e., purchasing something online).
2. A participating resources (Starbucks App, Starbucks cash register, and the Starbucks servers) are in a consistent state at the beginning and the end of a transaction.
3. Each transaction must complete on an all-or-nothing basis.

A transaction should adhere to the terms of the ACID properties.

• Atomicity is where each step in the transaction process must be completed successfully or all work must be rolled back ( all-or-nothing principle).
• Consistency is where the system(s) resources must be in a consistent, noncorrupted STATE at the start and end of a transaction process. If money is transferred between savings and checking accounts, the combined balance should not change after the transaction has been committed to the database.
• Isolation is where an individual transaction must not be visible to other open transactions until the transaction commits successfully. Example: The inventory item counts goes down by how many items included in the transaction, when the transaction is committed to the database.
• Durability is the result of a completed transaction is that the transaction must be made permanent or persistent to the database. It must survive a crash or mishap of any sort. A good example for me was working with billing systems were no transaction was ever completed and lacked a usable audit trail.

Transaction resources are the various systems a transaction touches or impacts or triggers during the transaction process. Example: database, message queues, printers, ATM machines, apps, etc.

Long transaction is a transaction that spans multiple requests and/or sessions. Example: online shopping cart, load application process, completing tax returns, travel booking, and creating a growth engine model.

Request transaction

Late transaction is where you keep a transaction open as long as possible.

Transaction liveness is

Lock Escalation if a transaction locks rows in a database, at some point the database may have more locks than it can handle that escalates to the locking of the entire table. Your code makes demands or requests on various resources. Another your code creates various tasks for the objects within your application. Remember the capacity of all system resources, whether physical or digital, are finite. You have to know the maximum capacity of every aspect of your application.

Transaction Isolation

• Serialize transaction is where transactions are fully isolated. Transactions are serializable if they can be processed or executed concurrently where the result is not effected regardless of the sequence.
• Repeatable Read allows for phantoms items. A phantom occurs when you add some elements to a collection and the reader sees only some of the elements. Examples:
• Read Committed allows for unrepeatable reads. If you query a database table and and the query returns the count of 5 items, then Joe Test commits a new item to the table, then you rerun the query and the query returns the count of 6 items. The initial query of 5 items can’t not be reproduced therefore not repeatable.

• Read Uncommitted allows for dirty reads. This means the queries or reads include uncommitted transactions.

  Isolation Level	Dirty Reads	Unrepeatable Read	Phantoms
  Read Uncommitted	Yes	Yes	Yes
  Read Committed	No	Yes	Yes
  Repeatable Read	No	No	Yes
  Serializable	No	No	No

Concurrency is the ability of a system to execute multiple tasks or processes simultaneously.

Best Practices

1. Break long transactions into a series of short transactions.

Offline Concurrency patterns are used to handle business transactions executed over a series of system transactions. Once outside of the confines of a single transaction process, the database manager alone is able to assure that the business transaction will leave record data in a consistent state.

Transactions are closely connected to user sessions.

Read Lock This is a lock that affects retriving a record set for purposes of reading only. This includes system and user reads. For example, the system may access a customer’s address to select the correct sales tax rate.

Write Lock This is a lock that affects the ability to edit a record set.

Version Count this is a field within the table that is used by the optimistic offine lock method.

Deadlock can occur when a system uses the pessimistic-offline-lock method. For example, Joe is editing Customer X, which places a lock on the record set. Bill, in the meanwhile, edits a Customer X order, which places a lock on the order. If Bill realizes that he needs to edit Customer X record set, he can’t because of the lock that Joe has initiated. If Joe realizes that he needs to make a change to Customer X order, he can’t because of the lock that Bill has initiated. That’s a deadlock.

One way to resolve deadlocks is through code. The code needs to be able: i) identify that a deadlock has occured, ii) select a victim based on a criteria, iii) resolve the deadlock, and iv) communicate the resolution to all parties involved in the deadlock.