Yes by charge, I meant checkout It has been a long time since I have run across an instance of this happening and as far as I know, the problem doesn't exist in our version 1.4.0.7.
Once to find instances of double checkouts, I created a report that pulled up patron checkouts where the Circ ID# was greater than the Copy ID#, and was able to compile a small list. George Tuttle Computer Services Librarian Piedmont Regional Library System 770-867-2762 x103 770-891-0654 (cell) 770-867-7483 (fax) [email protected] -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Jason Etheridge Sent: Wednesday, March 17, 2010 2:28 PM To: Evergreen Discussion Group Subject: Re: [OPEN-ILS-GENERAL] Check out issue > 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/
