"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;

"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

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

<< 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

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

"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

<< 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