Hi all,
Is there any way to speed up the time it takes before a record locking error (# 61) notification appears? I'm using BR 4.18g, and it takes 15 seconds (on a local workstation, not a network) from the time BR attempts to read the record to the time the error appears.
It's easy for the user to think that her workstation is frozen with that siginificant of a delay. The file is open OUTIN, SHR with two indexes. There are only 330 records in the file.
-- Susan
Record lock - notification delay
Moderators: Susan Smith, admin, Gabriel
-
Susan Smith
- Posts: 717
- Joined: Sun Aug 10, 2008 4:24 am
- Location: Southern California
Susan,
Straight from the BR Manual:
By default, Business Rules fifteen seconds for a locked record
to become available before it returns a locked-record error (error code 0061) to the
user requesting the second READ. The time to wait for a locked record can be
defined in the OPEN statement using the WAIT= parameter.
OPen #file, ......................, wait=5 - instead of 15 should solve this
Straight from the BR Manual:
By default, Business Rules fifteen seconds for a locked record
to become available before it returns a locked-record error (error code 0061) to the
user requesting the second READ. The time to wait for a locked record can be
defined in the OPEN statement using the WAIT= parameter.
OPen #file, ......................, wait=5 - instead of 15 should solve this
Record Locking
Record Locking is treated as an I/O error, and as such is retried several times.
To make things worse, the network tries a few times as well. 15 seconds sounds about right. I know you are using a local machine, but that still follows these rules.
In theory, this helps to reduce problems because the automatic retry will prevent a user error when the record is temporarily locked.
Read,Release will bypass the record locking, and can be used when locks are not important.
Overall, we treat this situation as a "Bug" in our software. A record should not be locked for an extended time.
We read the claim with a lock, to make sure that someone else doesn't have the claim locked (for example posting a financial transaction), we make a "Before Copy" of the data, then we release the lock, so that other users may review the claim as well. When it's time to re-write the data, we lock the record again, check to see if someone else changed the data while the user made changes, and "Merge The Results".
The end result is the record is only locked for a very brief period before & after the user works the record.
We also make sure that any "Read Only" operation uses "Read, Release" or even better "Open Input". Both of these operations are much faster than locking the record, and prevent contention.
As I think about your sitation, are you running two copies of BR? If not, then your application has the table open twice, and is locking both handles.
To make things worse, the network tries a few times as well. 15 seconds sounds about right. I know you are using a local machine, but that still follows these rules.
In theory, this helps to reduce problems because the automatic retry will prevent a user error when the record is temporarily locked.
Read,Release will bypass the record locking, and can be used when locks are not important.
Overall, we treat this situation as a "Bug" in our software. A record should not be locked for an extended time.
We read the claim with a lock, to make sure that someone else doesn't have the claim locked (for example posting a financial transaction), we make a "Before Copy" of the data, then we release the lock, so that other users may review the claim as well. When it's time to re-write the data, we lock the record again, check to see if someone else changed the data while the user made changes, and "Merge The Results".
The end result is the record is only locked for a very brief period before & after the user works the record.
We also make sure that any "Read Only" operation uses "Read, Release" or even better "Open Input". Both of these operations are much faster than locking the record, and prevent contention.
As I think about your sitation, are you running two copies of BR? If not, then your application has the table open twice, and is locking both handles.
-
Susan Smith
- Posts: 717
- Joined: Sun Aug 10, 2008 4:24 am
- Location: Southern California
Thanks Doug and Luis.
The light bulb is quite illuminating!
I will be using a standard open function for these files in the future, so I have to come up with something generic that works for most files and most situations. It is ultimately run on a network, but I am testing on a single computer.
Doug - you used an example of WAIT=5. In your experience (aside from hardware and software configuration differences), is this typically a reasonable compromise? I want to avoid MOST situations where there is a record locking notification delay due to one user is editing a record and another reading through the file opened as OUTIN? I don't believe that reading the file with RELEASE is an option in this case for other reasons.
-- Susan
The light bulb is quite illuminating!
I will be using a standard open function for these files in the future, so I have to come up with something generic that works for most files and most situations. It is ultimately run on a network, but I am testing on a single computer.
Doug - you used an example of WAIT=5. In your experience (aside from hardware and software configuration differences), is this typically a reasonable compromise? I want to avoid MOST situations where there is a record locking notification delay due to one user is editing a record and another reading through the file opened as OUTIN? I don't believe that reading the file with RELEASE is an option in this case for other reasons.
-- Susan
Susan,
If a record is locked, the wait time is user definable in the open stmt if you override using wait=xx. 5 was just an example, but less than the default of 15 seconds.
In my maintenance programs, I always open files to be written with internal, outin. and read the record in with , release - to not have the record locked.
When I get ready to rewrite the record after doing maint,
read #file, key=key$ - the record is now locked
rewrite #file - with the changed data. - the record is released after rewrite
as Louis suggested. This way, you never have a record open too long and it is locked only for the rewrite.
If a record is locked, the wait time is user definable in the open stmt if you override using wait=xx. 5 was just an example, but less than the default of 15 seconds.
In my maintenance programs, I always open files to be written with internal, outin. and read the record in with , release - to not have the record locked.
When I get ready to rewrite the record after doing maint,
read #file, key=key$ - the record is now locked
rewrite #file - with the changed data. - the record is released after rewrite
as Louis suggested. This way, you never have a record open too long and it is locked only for the rewrite.