I have inherited a Delphi 2006/DBISAM 4.25 application that has perhaps a dozen concurrent users in which all of the applications run with the
following settings:

TableReadLockRetryCount=32768
TableWriteLockRetryCount=32768
TableTransLockRetryCount=32768

I wasn't able to learn from the DBISAM manual what the defaults for these values are, but I gather from various threads that 15 might be a
reasonable number (one thread said that 250 was too high).  

Can the application's extreme values do anything except guarantee that a deadlock will never be resolved (I ask because this is what appears to
have happened in our deployed system)?

Thanks.

Jim,

<< I have inherited a Delphi 2006/DBISAM 4.25 application that has perhaps a
dozen concurrent users in which all of the applications run with the
following settings:

TableReadLockRetryCount=32768
TableWriteLockRetryCount=32768
TableTransLockRetryCount=32768

I wasn't able to learn from the DBISAM manual what the defaults for these
values are, but I gather from various reads that 15 might be a reasonable
number (one thread said that 250 was too high). >>

The only one that you should change, if you feel it is necessary, is the
TableTransLockRetryCount, and the most common reason for such a change is to
cause transactions that are waiting on a lock to fail faster and report back
the lock exception to the user or application.  The read and write lock
retry counts and wait times should be left alone.

<< Can the application's extreme values do anything except guarantee that a
deadlock will never be resolved (I ask because this is what appears to have
happened in our deployed system)? >>

Read, write, and transaction locks can never deadlock.  However, transaction
locks can cause other writers to wait, which is why you should always keep
transactions as short as possible.  If you are experiencing a situation
where other users appear to be stalled during a Post or SQL INSERT, UPDATE,
or DELETE operation, then you should make sure that there aren't any
transactions in the system that are waiting on user input or other types of
external input that could make the transaction wait for a long period of
time.

--
Tim Young
Elevate Software
www.elevatesoft.com

Tim,

Thank you for your prompt reply.   I will leave the values alone until I have a more definitive symptom, but I would like to understand
the meaning of the LockRetryCounts:

1) is 32768 the default value for the various LockRetryCounts?

2) with a LockWaitTime of 3 (milliseconds), does a LockRetryCount of 32768 mean a wait of ~98 seconds before an exception is thrown?

3) should I conclude that values ranging from 15 to 250 that I found in other threads (e.g., http://www.elevatesoft.com/newsgrp?
action=searchopenmsg&group=5&msg=16898&keywords=lockretrycount*#msg16898) were discussing a different LockRetryCount or
an older version of DBISAM?

Thanks again,

Jim



"Tim Young [Elevate Software]" wrote:

Jim,

<< I have inherited a Delphi 2006/DBISAM 4.25 application that has perhaps a
dozen concurrent users in which all of the applications run with the
following settings:

TableReadLockRetryCount=32768
TableWriteLockRetryCount=32768
TableTransLockRetryCount=32768

I wasn't able to learn from the DBISAM manual what the defaults for these
values are, but I gather from various reads that 15 might be a reasonable
number (one thread said that 250 was too high). >>

The only one that you should change, if you feel it is necessary, is the
TableTransLockRetryCount, and the most common reason for such a change is to
cause transactions that are waiting on a lock to fail faster and report back
the lock exception to the user or application.  The read and write lock
retry counts and wait times should be left alone.

<< Can the application's extreme values do anything except guarantee that a
deadlock will never be resolved (I ask because this is what appears to have
happened in our deployed system)? >>

Read, write, and transaction locks can never deadlock.  However, transaction
locks can cause other writers to wait, which is why you should always keep
transactions as short as possible.  If you are experiencing a situation
where other users appear to be stalled during a Post or SQL INSERT, UPDATE,
or DELETE operation, then you should make sure that there aren't any
transactions in the system that are waiting on user input or other types of
external input that could make the transaction wait for a long period of
time.

--
Tim Young
Elevate Software
www.elevatesoft.com

Jim,

<< 1) is 32768 the default value for the various LockRetryCounts? >>

Yes.

<<  2) with a LockWaitTime of 3 (milliseconds), does a LockRetryCount of
32768 mean a wait of ~98 seconds before an exception is thrown? >>

Yes.

<< 3) should I conclude that values ranging from 15 to 250 that I found in
other threads (e.g.,
http://www.elevatesoft.com/newsgrp?action=searchopenmsg&group=5&msg=16898&keywords=lockretrycount*#msg16898)
were discussing a different LockRetryCount or an older version of DBISAM? >>

Yes, that thread was discussing the LockRetryCount and LockWaitTime
properties of the TDBISAMSession component, which apply to record locks, not
the internal read/write/trans locks used by the DBISAM engine.  You can see
more information regarding this here:

http://www.elevatesoft.com/manual?action=mantopic&id=dbisam4&product=d&version=7&category=2&topic=1

--
Tim Young
Elevate Software
www.elevatesoft.com