Task #5802 (new)
Add further ConcurrencyException handling
|Reported by:||jamoore||Owned by:||jburel|
As a follow on to #5639, it would be good if clients could also handle ConcurrenyException and subclasses coming from other API methods. For that ticket, I added a mapping from the postgresql deadlock detected exception to our concurrency exception, but the change didn't get propagated to the clients. What this means is that two threads/processes/clients tried to modify the same rows but in a different order. Postgresql throws an exception on only one of the threads (the "loser" thread) so that the server doesn't block. That thread can in most contexts be safely retried.
Passing to J-M for implementation in Insight first (after 4.3.0 release)
Note: in the specific case of #5639, this wouldn't have helped, since the exception was encoded in the reports return value from DeleteHandle. We should also address how to properly communicate to the clients exactly which exception was thrown.