[OPEN-ILS-GENERAL] Check out issue

Daniluk, Judy jdaniluk at ntrls.org
Wed Mar 17 19:03:23 EDT 2010

We saw something similar on a few occasions while we were on
We noticed it mostly during 'renew' operations - after renewing the item
would be listed twice in the patron's 'items out' screen.

We have now upgraded to and haven't seen it (yet) in that

Judy Daniluk
Technology Consultant,  North Texas Library Partners
6320 Southwest Blvd., Suite 101, Fort Worth, TX 76109
jdaniluk at ntrls.org     817-201-6778 (cell)     817-377-4440 (office)

-----Original Message-----
From: open-ils-general-bounces at list.georgialibraries.org
[mailto:open-ils-general-bounces at list.georgialibraries.org] On Behalf Of
George Tuttle
Sent: Wednesday, March 17, 2010 2:06 PM
To: 'Evergreen Discussion Group'
Subject: Re: [OPEN-ILS-GENERAL] Check out issue

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 

Once to find instances of double checkouts, I created a report that
up patron checkouts where the Circ ID# was greater than the Copy ID#,
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
> an item, hits refresh, and charges it again. I associate the problem
> 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

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

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.

More information about the Open-ils-general mailing list