5867cf7a40
While this won't prevent the deadlock, it should catch the case where a deadlock causes the DB update to fail and provide feedback to the user and rollback the transaction I don't know how to trigger the deadlock, I can only confirm that we see it, and that this should catch it. To test: 1 - Apply patches 2 - Checkout several items to a patron 3 - Confirm that 'Renew all' feature continues to work as expected and all items are renewed Signed-off-by: David Nind <david@davidnind.com> Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl> Bug 26457: Unit test Signed-off-by: David Nind <david@davidnind.com> Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl> Bug 26457: (QA follow-up) Switch to PK index in UPDATE on issues The deadlock reports tell us that multiple transactions are waiting for a X lock on a record but using a secondary index on borrowernumber and itemnumber. Since we have the issue_id at hand already, we should use that and benefit from the clustered index (on PK) instead of using a secondary index. Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl> Signed-off-by: Victor Grousset/tuxayo <victor@tuxayo.net> |
||
|---|---|---|
| .. | ||
| Checkouts | ||
| Patron | ||
| Account.pm | ||
| Authentication.pm | ||
| Authorization.pm | ||
| Checkout.pm | ||
| ClubHold.pm | ||
| Config.pm | ||
| Elasticsearch.pm | ||
| Exception.pm | ||
| Hold.pm | ||
| Ill.pm | ||
| Library.pm | ||
| Metadata.pm | ||
| Object.pm | ||
| Password.pm | ||
| Patron.pm | ||
| Plugin.pm | ||
| Token.pm | ||