We've recently moved a DBISAM client server system from DBISAM 4.30 (running smoothly for many months/years) to 4.34 build 4.

Within 24 hours of running the new server and updated clients (also 4.34 build 4) exceptions begin to be raised when any client attempts a WRITE operation of any sort (all READ operations continue to work just fine). We have to restart the DBISAM server for functionality to be restored, whereupon the problem reemerges within another 24 hours.

This has become a very serious issue and is causing substantial business interruption.

From today's server log here is the first occurrence of this error.

24/01/2013 8:54:27 AM [ERROR] Engine error [DBISAM Engine Error # 10243 Cannot lock the session (ID: 54)] [Client Version: 4.34 User Name:  Address: 192.168.17.230 Encrypted: Yes Request: REQUEST_RECONNECT Thread: 2128 Session: 0]

Many similar error messages appear soon after such as

24/01/2013 8:55:15 AM [ERROR] Engine error [DBISAM Engine Error # 10243 Cannot lock the session (ID: 54)] [Client Version: 4.34 User Name:  Address: 192.168.17.230 Encrypted: Yes Request: REQUEST_RECONNECT Thread: 3120 Session: 0]

24/01/2013 8:56:14 AM [ERROR] Engine error [DBISAM Engine Error # 10243 Cannot lock the session (ID: 54)] [Client Version: 4.34 User Name:  Address: 192.168.17.230 Encrypted: Yes Request: REQUEST_RECONNECT Thread: 2852 Session: 0]

and then we start to see other errors such as

24/01/2013 8:58:59 AM [ERROR] Engine error [DBISAM Engine Error # 10229 Transaction cannot lock the database 'AIMS'] [Client Version: 4.34 User Name: AIMSFld Address: 220.233.103.95 Encrypted: Yes Request: REQUEST_STARTTRANS Thread: 2924 Session: 18]

24/01/2013 8:59:19 AM [ERROR] Engine error [DBISAM Engine Error # 10229 Transaction cannot lock the database 'AIMS'] Additional info [DELETE FROM ClientSet WHERE WorkerID = 749
] [Client Version: 4.34 User Name: AIMSMgr Address: 192.168.17.230 Encrypted: Yes Request: REQUEST_EXECUTESTMT Thread: 3276 Session: 54]

The bulk of the errors however are the 10243 error.

I've looked all through the DBISAM documentation on locking and concurrency and I can't see any references to session locks. Is this something we have to manage in this new version of DBISAM? If so what are we likely doing wrong to cause this error.

We're running the 32 bit dbsrvr.exe compiled with XE2 with just one customisation, a remote procedure that returns the clients IP address to them. This procedure has not changed in years though.

procedure TMainForm.ServerEngineServerProcedure(Sender: TObject; ServerSession: TDBISAMSession;
     const ProcedureName: String);
var
 SessionNum, SessionID, TargetSessionID, Count: Integer;
 CreatedOn, LastConnectedOn: TDateTime;
 UserName, UserAddress, LastUserAddress: String;
 Encrypted: Boolean;
begin
 if (AnsiCompareText(ProcedureName, 'GetClientIPAddress') = 0) then begin
   SessionID := 0;
   Count := ServerEngine.GetServerSessionCount;
   with ServerSession do begin
     TargetSessionID := RemoteParams.ParamByName('CurrentRemoteID').AsInteger;
     RemoteParams.Clear;
     for SessionNum := 1 to Count do begin
       ServerEngine.GetServerSessionInfo(SessionNum, SessionID, CreatedOn, LastConnectedOn, UserName, UserAddress,
             Encrypted, LastUserAddress);
       if (SessionID = TargetSessionID) then begin
         RemoteParams.CreateParam(ftString, 'IPAddress').AsString := UserAddress;
         Break;
       end
     end;
     if not(SessionID = TargetSessionID) then
       RemoteParams.CreateParam(ftString, 'IPAddress');
   end;
 end;
end;

Thanks very much for your time,

Lachlan Gemmell
Embarcadero MVP

Lachlan,

Have you emailed elevate software support direct
(support@elevatesoft.com) ?  If not please do so as these forums are
peer-support and i'm sure you'll receive responses but ElevateSoft
support is only authoritative source.

On 1/23/2013 8:48 PM, LachlanG wrote:
<< Within 24 hours of running the new server and updated clients (also
4.34 build 4) exceptions begin to be raised when any client attempts a
WRITE operation of any sort (all READ operations continue to work just
fine). We have to restart the DBISAM server for functionality to be
restored, whereupon the problem reemerges within another 24 hours. >>

Definitely sounds like locking issues.

Are you using transaction in your application (update and delete use
implicit transactions - i assume you use those)?

What about lengthy read operations (those could result in write locks as
well).

No idea why it would work ok in 4.30 - looking at incident reports there
are number of fixes in 4.34 (relative to 4.30) but i have not heard
anybody running into this scenario with new version .


<< > 24/01/2013 8:54:27 AM [ERROR] Engine error [DBISAM Engine Error #
10243 Cannot lock the session (ID: 54)] [Client Version: 4.34 User Name:
 Address: 192.168.17.230 Encrypted: Yes Request: REQUEST_RECONNECT
Thread: 2128 Session: 0]>>

This one looks like an internal error - Elevate support likely best
source for this one as it's internal locking done by dbisam in dbsrvr
and not anything we'd do in code (or would need to).


<< > 24/01/2013 8:58:59 AM [ERROR] Engine error [DBISAM Engine Error #
10229 Transaction cannot lock the database 'AIMS'] [Client Version: 4.34
User Name: AIMSFld Address: 220.233.103.95 Encrypted: Yes Request:
REQUEST_STARTTRANS Thread: 2924 Session: 18]>>

Are you using transactions and/or lengthy read operations that might
result in this locking?



<<> We're running the 32 bit dbsrvr.exe compiled with XE2 with just one
customisation, a remote procedure that returns the clients IP address to
them. This procedure has not changed in years though.>>

Any way you can use the default dbsrvr (just for test)?

Was the old version also compiled on XE2? (only reason i'm asking is
that official support for XE2 was added in 4.31 and not in 4.30 - though
it might have worked as well).

Raul

Raul wrote:

<<Are you using transaction in your application (update and delete use
implicit transactions - i assume you use those)?>>

Almost all write operations are done on editable query result sets and follow the format recommended for cached updates in the DBISAM documentation namely

  TablesList:=TStringList.Create;
  try
     TablesList.Add('SomeTableName');
     Database.StartTransaction(TablesList);
     try
        MyQuery.ApplyCachedUpdates;        
        Database.Commit;
     except
        Database.Rollback;
        raise;
     end;
  finally
     TablesList.Free;
  end;

<<What about lengthy read operations (those could result in write locks as
well).>>

We have discovered in our most recent client release a bug that does pull down an excessive amount of records. It's been addressed but not yet deployed as the work involved in deploying a new client release is currently quite considerable. If it turns out to be our fault rather than DBISAM's I won't be surprised if this bug is the cause. I am curious as to why it would throw an exception about session locking though rather than table locking.

<<Any way you can use the default dbsrvr (just for test)?>>

Not without a new client rollout which as I said earlier is a non-trivial operation. We really need to be pretty confident that our next client rollout will be the one that fixes this.

<<Was the old version also compiled on XE2?>>

No, Delphi 5.

Thanks for your assistance,

Lachlan Gemmell
Embarcadero MVP

Lachlan,

<< The bulk of the errors however are the 10243 error.

I've looked all through the DBISAM documentation on locking and concurrency
and I can't see any references to session locks. Is this something we have
to manage in this new version of DBISAM? If so what are we likely doing
wrong to cause this error. >>

This error occurs when:

1) The client (remote session) initiates an operation on the DBISAM Database
Server that takes a very long time to complete.
2) The client then times out and disconnects.
3) The client then tries to re-connect to the existing session, but cannot
because the session is still in the middle of trying to complete the lengthy
operation.  The session lock error occurs because each session on the server
has a lock on it while it is executing a request in order to prevent the
server from trying to execute another request on the same thread/session
while it's already busy.

If you have any other questions, please let me know.

Tim Young
Elevate Software
www.elevatesoft.com

Lachlan,

<< We have discovered in our most recent client release a bug that does pull
down an excessive amount of records. It's been addressed but not yet
deployed as the work involved in deploying a new client release is currently
quite considerable. If it turns out to be our fault rather than DBISAM's I
won't be surprised if this bug is the cause. I am curious as to why it would
throw an exception about session locking though rather than table locking.
>>

Does this bug cause the server to take an inordinate amount of time (> 60
seconds) trying to complete a particular operation ?  If so, then it would
definitely be a candidate for causing the "session lock" issue, and the fact
that it involves a transaction would definitely make it a candidate for
causing the normal transaction/write lock errors.

Thanks,

Tim Young
Elevate Software
www.elevatesoft.com