Login ProductsSalesSupportDownloadsAbout |
Home » Technical Support » DBISAM Technical Support » Support Forums » DBISAM General » View Thread |
Messages 11 to 17 of 17 total |
Cursor, DataSet fluidity, preservation of records? |
Wed, Mar 17 2010 6:15 AM | Permanent Link |
Robert Kaplan | "Roy Lambert" <roy.lambert@skynet.co.uk> wrote in message news:37462A28-159F-4B4D-BF60-7AD1BC59BE0F@news.elevatesoft.com... > Robert > >>Check semaphore locks. > > I thought about those, but (from memory) they're limited to 255 per table > so I ignored them. > > Roy Lambert [Team Elevate] > 1024 per table. But the key is that many times you need just one. You pick specific numbers to mean specific things, like if semaphore 123 is active on table ABC, then wait before starting some activity, then test again. BTW the table used for semaphores has nothing to do with the actual activity being monitored. I use a table that I know will be accessed in every application (company parameters, that type of thing). Const SemBatchActive = 123; Procedure DoSomethingThatRequiresSingleAccess; var Tries : Integer; tries := 0; while not MyTable.Locksemaphore(SemBatchActive) do begin inc(tries); if tries > 90 then raise... sleep(10); end; try do something; finally MyTable.UnlockSemaphore(SemBatchActive); end; |
Wed, Mar 17 2010 6:52 AM | Permanent Link |
durumdara | "Robert" wrote:
>>Check semaphore locks. > > I thought about those, but (from memory) they're limited to 255 per table > so I ignored them. > > Roy Lambert [Team Elevate] > But what happened when the client that maked a lock crashed? I need to wait for 5 minutes with other clients? Or what? Thanks: dd |
Wed, Mar 17 2010 7:40 AM | Permanent Link |
Roy Lambert NLH Associates Team Elevate | Robert
>> I thought about those, but (from memory) they're limited to 255 per table >> so I ignored them. >1024 per table. It just has to be age Roy Lambert |
Wed, Mar 17 2010 10:58 AM | Permanent Link |
Tim Young [Elevate Software] Elevate Software, Inc. timyoung@elevatesoft.com | << But what happened when the client that maked a lock crashed?I need to wait for 5 minutes with other clients? Or what? >> Using pinging (RemotePing=True) on all of the clients with a RemotePingInterval of 30 seconds, set the Session Timeout value to 60 seconds on the server, and set the Dead Session Expiration Time to 30 seconds on the server. That will mean that the server will wait a maximum of 90 seconds, or 1 1/2 minutes, before it detects that the session is gone and removes the session/releases the locks. -- Tim Young Elevate Software www.elevatesoft.com |
Wed, Mar 17 2010 10:59 AM | Permanent Link |
Tim Young [Elevate Software] Elevate Software, Inc. timyoung@elevatesoft.com | Roy,
<< I know they are released when the app using them closes or crashes and as it says in the manual when the dataset is closed but what happens when in a c/s environment the session bombs? At what point are they released? When the session goes or after the dead session cleanup time or something else entirely different? >> See my reply in the other part of the thread: http://www.elevatesoft.com/forums?action=view&category=dbisam&id=dbisam_general&page=1&msg=63710#63710 -- Tim Young Elevate Software www.elevatesoft.com |
Wed, Mar 17 2010 12:02 PM | Permanent Link |
durumdara | "Tim Young [Elevate Software]" wrote:
<< But what happened when the client that maked a lock crashed?I need to wait for 5 minutes with other clients? Or what? Using pinging (RemotePing=True) on all of the clients with a RemotePingInterval of 30 seconds, set the Session Timeout value to 60 seconds on the server, and set the Dead Session Expiration Time to 30 seconds on the server. That will mean that the server will wait a maximum of 90 seconds, or 1 1/2 minutes, before it detects that the session is gone and removes the session/releases the locks.>> Dear Tim! As I understand the lock remove is happening in "Session Remove". Hmmmm.... We don't have, only manual ping (DBISAM, 3.30), a Timer that sometimes (1-2 minutes) pinging the server. When we have big CPU loading, and two of the pings are "lost", we can reconnect before session died. 60 seconds seems to be very low for "Timer" based solution... What do you think: can I share a DataBase handle between threads? May I create my own Pinging thread - but the problem that in common solutions we need separate Session/DB for each thread, and Synchronize also not too good because of "Application Message Queue" released until the long process finished... So what is the best way for this version? Thanks for your help: dd |
Wed, Mar 17 2010 4:38 PM | Permanent Link |
Tim Young [Elevate Software] Elevate Software, Inc. timyoung@elevatesoft.com | << As I understand the lock remove is happening in "Session Remove". >> Yes, that is correct. << We don't have, only manual ping (DBISAM, 3.30), a Timer that sometimes (1-2 minutes) pinging the server. When we have big CPU loading, and two of the pings are "lost", we can reconnect before session died. 60 seconds seems to be very low for "Timer" based solution... What do you think: can I share a DataBase handle between threads? >> The quick answer is no, you cannot. << May I create my own Pinging thread - but the problem that in common solutions we need separate Session/DB for each thread, and Synchronize also not too good because of "Application Message Queue" released until the long process finished... So what is the best way for this version? >> There really isn't any "best" way in DBISAM 3.x. DBISAM 4.x and ElevateDB use internal synchronization primitives that allow it to have a pinging thread share the same connection to the database server. You could do the same with 3.x, but you'd have to modify the source code in order to do so. -- Tim Young Elevate Software www.elevatesoft.com |
« Previous Page | Page 2 of 2 | |
Jump to Page: 1 2 |
This web page was last updated on Wednesday, April 24, 2024 at 11:07 AM | Privacy PolicySite Map © 2024 Elevate Software, Inc. All Rights Reserved Questions or comments ? E-mail us at info@elevatesoft.com |