Login ProductsSalesSupportDownloadsAbout |
Home » Technical Support » DBISAM Technical Support » Support Forums » DBISAM General » View Thread |
Messages 1 to 4 of 4 total |
Reasonable values for LockRetryCounts |
Thu, Jun 25 2009 5:14 PM | Permanent Link |
Jim Mueller | 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. |
Thu, Jun 25 2009 8:43 PM | Permanent Link |
Tim Young [Elevate Software] Elevate Software, Inc. timyoung@elevatesoft.com | 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 |
Fri, Jun 26 2009 8:40 AM | Permanent Link |
Jim Mueller | 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 |
Fri, Jun 26 2009 11:53 AM | Permanent Link |
Tim Young [Elevate Software] Elevate Software, Inc. timyoung@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 |
This web page was last updated on Tuesday, September 17, 2024 at 04:19 AM | Privacy PolicySite Map © 2024 Elevate Software, Inc. All Rights Reserved Questions or comments ? E-mail us at info@elevatesoft.com |