4
  • My applications uses error reporting to track exceptions.
  • My application uses SQL transactions to make sure that operations are completed completely or not at all.
  • My application is multi-threaded.
  • Exceptions will occur when more than 1 transaction attempts to do the same thing. This is good because only 1 of them should succeed.
  • When a collision does occur, an exception is raised and reported.
  • Investigating exceptions takes time.

How should my application handle "safe" exceptions like this?

Notes:

  • It may be difficult to differentiate "safe" and "unsafe" exceptions because the exception raised would be from the database module and the message will likely be generic.
  • Exceptions caused by "safe" collisions could have different error messages depending on which point in the transaction that the error occurred at.
3

Depending on the kind of application, and - sometimes - depending on the specific transaction, you need to pick one of the following options:

  1. The first change wins (the second transaction is rollbacked).

  2. The second change wins (the second transaction is commited regardless of the exception, which may be used just for logging).

  3. A user (usually the one who initiated the second change) needs to decide interactively which of the two changes shall win.

  4. One finds a solution where the system can automatically decide between #1 and #2 on a by-case basis.

For #3, a user may need to have a look at the data of both changes to make a qualified decision, so this can become quite some effort to implement. In some applications it can make sense to offer the user an option of merging parts of both changes into a combined one (for example, Wikipedia offers such a model when two users try to edit the same article at the same time).

Unfortunately, there is no one-size-fits-all solution, you need to analyse the requirements in detail, then pick the trade-off of your choice.

1
  • I would suggest providing transactions with correlation Ids so these can be easily located and filtered in logs. The correlation ID must be present in the exception report to ease the "Investigations".
    – Laiv
    Feb 2 at 13:45
1

My applications uses error reporting to track exceptions

From reading this, I would suggest that you appear to have your own definition of "exception".

... SQL transactions ... operations are completed completely or not at all.

So you have atomic transactions. Good.

My application is multi-threaded

That's not a problem because you have atomic transactions.

Exceptions will occur when more than 1 transaction attempts to do the same thing ... only 1 of them should succeed.
When a collision does occur, an exception is raised and reported.
Investigating exceptions takes time

I regard just reporting Exceptions as a kind of "last-resort".
It's far better for the catching code to do something about the Exception so that, ideally, by the time that catching code completes, it's as if the Exception never happened. In the case of database transactions, though, that may not be practical because, by definition, the data "landscape" will have changed since your first attempt (upset by the other transaction, which worked). Giving the User the option to try again is more workable.

Most Exceptions thrown by Data Access frameworks will contain (ironically) some sort of error number/code or a "sql state". It may well vary by DBMS, but you should be able to interrogate these properties to find out whether the Exception is a "safe" one or a really "bad" one.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.