I'm working on a conveting an app from DBISAM to EDB.   One of the functions
that we used to keep track of active connections involved semaphore locks
and we kept the performance of all the lock checks up by setting the lock
wait time and lock retry count to zero before testing the locks and then
setting them back to the original values afterwards.  But EDB doesn't seem
to allow these values to be changed after the session is open.

I know that I could create another session. But with a large number of users
and each instance already making several connections to the server, it is
possible that we could hit the maximum number of session connections to a
remote server.

Any chance that EDB 2.02 (or 2.03) could possibly allow the application to
change these two properties on an open session?

--

---------------------------------------
 Terry Swiers
 Millennium Software, LLC
 http://www.1000years.com
 http://www.atrex.com

 Atrex Inventory Control/POS -
    Big business features without spending big business bucks!

Atrex Electronic Support Options:
 Atrex Knowledgebase: http://www.atrex.com/atrexkb.asp
 Email: mailto:support@atrex.com
 Newsgroup: news://news.1000years.com/millennium.atrex
 Fax: 1-925-829-1851
 Phone: 1-925-828-5892 (M-F, 9a-5p Pacific)
 ---------------------------------------

Terry


What are you using instead of the semaphore flags? I ask because in DBISAM I used this to managed the users logged into the app.

Roy Lambert

Roy,

> What are you using instead of the semaphore flags? I ask because in DBISAM
> I used this to managed the users logged into the app.

I have a table in which I insert a record for each user and then use the
LockCurrentRecord function to add a manual lock on the record.  From what I
can see, this works very similar to the way that Semaphor locks did and get
cleared automatically when the table gets closed.  When the user closes out
of the application, the record is unlocked and removed.   I also have a
routine that is called before requesting a new slot in the table that goes
through and deletes any entries that it can, so it's "self cleaning".

Once it's all done, I'd be more than happy to share it, but it still needs a
bit of work.

--

---------------------------------------
 Terry Swiers
 Millennium Software, LLC
 http://www.1000years.com
 http://www.atrex.com

 Atrex Inventory Control/POS -
    Big business features without spending big business bucks!

Atrex Electronic Support Options:
 Atrex Knowledgebase: http://www.atrex.com/atrexkb.asp
 Email: mailto:support@atrex.com
 Newsgroup: news://news.1000years.com/millennium.atrex
 Fax: 1-925-829-1851
 Phone: 1-925-828-5892 (M-F, 9a-5p Pacific)
 ---------------------------------------

Terry


>I have a table in which I insert a record for each user and then use the
>LockCurrentRecord function to add a manual lock on the record.

One problem with manuals getting updated is that you have to keep reading the damn things That looks like just what I want.

>Once it's all done, I'd be more than happy to share it, but it still needs a
>bit of work.

Brill, post to the extensions I for one would like to see it.

Roy Lambert

Roy,

<< One problem with manuals getting updated is that you have to keep reading
the damn things That looks like just what I want. >>

Yes, I should have brought that up in any discussion about the semaphore
locks, if I didn't already.  The manual row lock methods in the TEDBTable
(LockCurrentRecord, UnlockCurrentRecord, UnlockAllRecords) can be used to
implement durable manual row locks whose lifetime is from the Lock until the
Unlock calls, or the table is closed.  This means that you can lock a row in
a table, and it will stay locked through any Edit..Post sequences.

--
Tim Young
Elevate Software
www.elevatesoft.com

Tim


>Yes, I should have brought that up in any discussion about the semaphore
>locks, if I didn't already.

You didn't <vbg>

>The manual row lock methods in the TEDBTable
>(LockCurrentRecord, UnlockCurrentRecord, UnlockAllRecords) can be used to
>implement durable manual row locks whose lifetime is from the Lock until the
>Unlock calls, or the table is closed. This means that you can lock a row in
>a table, and it will stay locked through any Edit..Post sequences.

Re-reading the entry in the manual it says "current dataset is closed" above you say "table is closed". But "This method is only used in the context of the descendant TEDBTable, TEDBQuery, TEDBScript, and TEDBStoredProc components."

To clarify things for me:

I assume this refers to the underlying disk file so tedbtable/etc.close wouldn't free it if another tedbtable/etc held it open somewhere? Or is it one lock per component that has a lock applied?

what happens if a user crashes their copy of the app does that release it or is it a case of "all off"?

Roy Lambert

Roy,

<< I assume this refers to the underlying disk file so tedbtable/etc.close
wouldn't free it if another tedbtable/etc held it open somewhere? Or is it
one lock per component that has a lock applied? >>

The manual locks are segreated per table cursor, so they are released when
the table cursor is closed.   They are *not* handled on a per *physical*
table basis.

<< what happens if a user crashes their copy of the app does that release it
or is it a case of "all off"? >>

In that case it is like any other locking situation - the OS will release
them.  In the case of C/S, the EDB Server will release them when it cleans
up the dead session.

--
Tim Young
Elevate Software
www.elevatesoft.com

Tim


Brill, sounds more and more what I can use, but just doing a quick test - set up two events

procedure TForm1.Button11Click(Sender: TObject);
begin
users.LockCurrentRecord;
end;

procedure TForm1.Button12Click(Sender: TObject);
begin
users.UnlockCurrentRecord;
end;

I can open the app and click either button as often as I want. I do not have to lock the record first to unlock it. Open another copy of the app and I do get an exception when I try to lock the record but no reaction when I unlock it.

Question: is the only way of finding out if a lock has been set trying to set another one and waiting for the exception?

Roy Lambert

Roy,

<< I can open the app and click either button as often as I want. I do not
have to lock the record first to unlock it. Open another copy of the app and
I do get an exception when I try to lock the record but no reaction when I
unlock it.

Question: is the only way of finding out if a lock has been set trying to
set another one and waiting for the exception? >>

No, check the RecordIsLocked method - it indicates whether a row is locked
manually (and only for manual locks - pessimistic Edit row locks are not
indicated by this method).

--
Tim Young
Elevate Software
www.elevatesoft.com

Tim

> Question: is the only way of finding out if a lock has been set trying to
>set another one and waiting for the exception? >>
>
>No, check the RecordIsLocked method - it indicates whether a row is locked
>manually (and only for manual locks - pessimistic Edit row locks are not
>indicated by this method).

That's brilliant. I think you make a lovely cross reference source <vbg>

Any comment on the fact that it doesn't seem to be operating as described (ie the unlocking bit)?

Roy Lambert