> As far as I can tell, these double charges are due to latency. User charges > an item, hits refresh, and charges it again. I associate the problem with > the refresh button.
Charge = checkout? Do the timestamps on the circs support that? Your mention of the Refresh button makes me think of things other than checkouts. An item should not be listed on a checkout receipt twice, which is what Mary indicated. Early on the checkout interface was rigged to not allow duplicate barcodes in a given instance (to prevent accidental double-scans), and it doesn't rely on the network for this. There could be a logic error in the code somewhere allowing it. Or, they may be printing a receipt from the Items Out interface after duplicate circs were created some other way. There have been several problems with renewals that may pertain to this: 1) Early versions of the staff client did not accommodate for "replication lag" between a read-only database and the master database in clustered environments. So a renewal would be made against the master database, and then the staff client would query a read-only database for the current list of circulations, only the read-only database had not yet caught up with the master, so stale data would be displayed. Staff would see this, and either a) renew the item again (possibly creating duplicate circs if the system was under extreme load, since a renewal is a new circ under the hood), or b) hit the Refresh button several times, increasing the load on the system. The fix here was to make "authoritative" versions of certain staff client queries, which would always get their data from the master database, and not a read-only database (which is really most needed for just search queries in the first place). However, the OPAC is not yet using these authoritative methods for the My Account section, so that's a possible avenue we should investigate (with patron renewals). 2) There was a race condition with the Renew All function in Items Out, in 1.4 and later, that was first noticed in 1.6 where the condition happened more frequently. Let's say you selected 3 circulations, and hit Renew All. If the race condition was met, then 3 renewal attempts could have been made against just one of those circulations, instead of 1 attempt for each. Not only could this deplete the renewals on the affected circulation, it could also create duplicate open circs for one item. The timestamps for these would be very close, within fractions of a second of each other. This was fixed about 7 months ago, at least from the point of view of the interface. It'd be nice if the circ service and/or database could protect itself from rogue interfaces or network sputters spamming it with multiple checkout or renew attempts against a given item, but I don't expect that to be an easy fix. :( -- Jason Etheridge | VP, Tactical Development | Equinox Software, Inc. / The Evergreen Experts | phone: 1-877-OPEN-ILS (673-6457) | email: [email protected] | web: http://www.esilibrary.com Please join us for the Evergreen 2010 International Conference! It is being held April 20 - 23, 2010 at the Amway Grand Hotel and Convention Center, Grand Rapids, Michigan. http://www.evergreen2010.org/
