[OPEN-ILS-GENERAL] Check out issue

[George Tuttle]

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)
gtuttle at prlib.org

-----Original Message-----
From: open-ils-general-bounces at list.georgialibraries.org
[mailto:open-ils-general-bounces at list.georgialibraries.org] 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:  jason at esilibrary.com
 | 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/