Question

I saw this sentence not only in one place:

“A transaction should be kept as short as possible to avoid concurrency issues and to enable maximum number of positive commits.”

What does this really mean?

It puzzles me now because I want to use transactions for my app which in normal use will deal with inserting of hundreds of rows from many clients, concurrently.

For example, I have a service which exposes a method: AddObjects(List<Objects>) and of course these object contain other nested different objects.

I was thinking to start a transaction for each call from the client performing the appropriate actions (bunch of insert/update/delete for each object with their nested objects). EDIT1: I meant a transaction for entire “AddObjects” call in order to prevent undefined states/behaviour.

Am I going in the wrong direction? If yes, how would you do that and what are your recommendations?

EDIT2: Also, I understood that transactions are fast for bulk oeprations, but it contradicts somehow with the quoted sentence. What is the conclusion?

Thanks in advance!

Answer 1

A transaction has to cover a business specific unit of work. It has nothing to do with generic ‘objects’, it must always be expressed in domain specific terms: ‘debit of account X and credit of account Y must be in a transaction’, ‘subtract of inventory item and sale must be in a transaction’ etc etc. Everything that must either succeed together or fail together must be in a transaction. If you are down an abstract path of ‘adding objects to a list is a transaction’ then yes, you are on a wrong path. The fact that all inserts/updates/deletes triggered by a an object save are in a transaction is not a purpose, but a side effect. The correct semantics should be ‘update of object X and update of object Y must be in a transaction’. Even a degenerate case of a single ‘object’ being updated should still be regarded in terms of domain specific terms.