Transaction is a good option to delete children records?

Question

I have two tables, one table A that is the parent and other table B that is the children (1:N relationship).

If I want to delete the children records in the table B when I delete the parent in the table A, if I don't use cascade on delete in the data base, I would do it in the following way:

1. User A load the parent record in her context, then load all the children records in the context, mark all as deleted.
2. Other user add a new children.
3. User A save changes. Get an error of reference integrity because the register added by the second user is not in her context.

In this case, the first user can try load all the children again when the exception is raised, but a third user can add a new children and have the same problem. In theory, this can occur all the time and the first user wouldn't delete the parent.

For that reason, I am thinking to use a transaction to do the work.

1. First user starts a transaction.
2. First user mark as deleted the parent and save the changes. The parent is blocked in the database.
3. First user load all the children, marked as deleted.
4. First user save the changes.

In this case, I have a doubt, when the parent register is blocked by the first user, the ID of this parent can be use by other user as foreign key of a children record? Or the database does not allow to use the ID because in theory is a deleted record?

If the database does not allow to use the ID, the second user will get an exception when try to add a new children, for reference integrity, because the parent does not exists. So the problem is solved. It is not needed to do anything else.

However, if the database allows to use the ID of the blocked parent, I need to do two things:

In the method that delete the parent:

1. Load the parent, mark it as deleted and save changes. This block the register.
2. Load the children, mark them as deleted an save the changes.
3. accept the transaction.

In the method that added a children

1. Load the parent. If is blocked, the method wait until the register is free.
2. Add the new children.
3. Accept changes.

Really is not needed to load the parent in the context to delete the children, it would be an extra query to the database.

If the parent does not exists, get an exception an is not needed to do anything else, the user that try to added a new register now that is because the parent was deleted.

If the parent exists, the children can be added.

So I have two questions.

1. is a good idea to use a transaction to delete a parent record to ensure that all the children are deleted?

2. If a transaction is a good option, when the parent is blocked, the data base does not allow to use the parent ID to add a new record or I need to do the solution to load the parent in the method that delete the children?

Answer 1

Transaction does not postpone delete operation. There is nothing like "marked as deleted" in the database. When you mark entity as deleted and execute SaveChanges the record is deleted in the database. It always happens in transaction. Once the record is about to be deleted FK constrains are checked and if any dependent record exists the error is thrown (unless ON DELETE rule for the constrain doesn't define other option). You must always delete children prior to parent when using FK constraints.

If your description is exact you may simply use the very first approach you are afraid of and close queries and SaveChanges into single TransactionScope. It will run transaction with serializable isolation level which should ensure that no other transaction will be able to insert record into locked key range (locked by the query) until current transaction completes.

While the solution with serializable transaction may work it can bring other issues - deadlocks with other transactions in your application. Because of that repeating failed transaction is often the best option. If your system has such a big concurrent load that delete transaction can fail "all the time" it is probably time to completely redesign your application.