Home/ Questions/Q 6212741
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-05-24T06:34:19+00:00

I’m looking for something similiar to an SQL transaction. I need the usual protections

  • 0

I’m looking for something similiar to an SQL transaction. I need the usual protections that transactions provide, but I don’t want it to slow down anyone else.

Imagine client A connects to the DB and runs these commands:

BEGIN TRAN
SELECT (something)
(Wait a few seconds maybe.)
UPDATE (something)
COMMIT

Inbetween the SELECT and the UPDATE, client B comes along and attempts to do a query, that under normal circumstances, would end up having to wait for A to COMMIT.

What I’d like is for client A to open it’s transaction in such a way that should B come along and perform it’s query, client A will find it’s transaction immediately rolled back and it’s subsequent commands failing. Client B would only experience minimal delay.

(Note that the SELECT and UPDATE are simply illustrative commands.)

Update…

I’ve got a high priority task (client B) that sometimes (once a month-ish) gets an SQL timeout error, and a low priority task (client A) with a transaction which causes that timeout. I’d rather that the low priority task fails and is reattempted in the next cycle.

I ended up fixing this problem by eliminating the transactions entirely and replacing them with an informal set of flags. The queries were refactored to only do something if the right set of flags are raised and I added something that cleared up abandoned records that the rollback would have cleared in the past.

I fixed my transaction issues by eliminating transactions.

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    While not a transaction at all, Optimistic Concurrency may be useful — it is used by default in LINQ2SQL, etc.

    The general idea is that the data is read — modifications can be independently made — and then the data written back with a “check” (this is loosely comparable to a Compare and Swap). If the check fails it is up the application to decide what to do (restart the process, proceed anyway, fail).

    This naturally doesn’t work for all scenarios and may not detect a number of interactions, such as new items added between the “read” and “write”. Both the actual read and write can be in separate transactions with the appropriate isolation level; the separate transactions may allow additional transactions to be interleaved.

    Of course, depending upon the exact problem and interactions… different isolation levels and/or finer grained locking may be sufficient.

    Happy coding.

    • 0