CIRC-1345
Link to the issue in JIRA tracket - CIRC-1345 - Getting issue details... STATUS
What alternatives are offered for analysis:
| Option | Good | Bad |
|---|---|---|
| Repeat item limit validation check immediately before loan creation (just duplicate row #125 before row #140) | Minimal effort at all | Repetitions of a heavyweight validation check (heavyweight - because during it a lot of data is pulled, including instance(s), holding(s), item(s), loan policy); the risk of race condition remains, although it decreases |
| Improve the second validation check - keep in context some of the data pulled during the first check (e.g.< loan policy, instance info) and reuse it during the second check | Minimal refactoring | Although the second check is much faster and lighter, the risk of a race condition still exists |
| Add a simple persistent counter of the number of open items at the patron level - increase it when creating a loan, decrease it when checking in, store it in the database. You will need to create a new table in mod-inventory-storage, API method to call. Working with the counter - through the select for update structure | Quite a simple and clear logical solution. Synchronization at the database level | Well, you need to carefully implement the work with the counter |
Move the logic for counting the number of open loans from Java code to SQL (as described in the comment to CIRC-1345 - Getting issue details... STATUS ) | Very point-to-point multi-thread synchronization at the DB level, which means lightness and minimal performance impact | As you can see on https://github.com/folio-org/mod-circulation/blob/946bb32ad4fe93fc505ce8bbec02964ce3ca76f7/src/main/java/org/folio/circulation/domain/validation/ItemLimitValidator.java#L76, checking the number of loans is not only a simple calculation, but also includes checking the status, material type and loan type. The doubt is to what extent row counting in the database can replace these checks, and to what extent such a solution can be extensible if necessary |
Note: the provided solutions can be considered as quite effective in the short and medium term. At the same time, adding full support for multi-threaded processing of check-out requests can be considered as one of the goals for refactoring an existing mod-circulation implementation.