Login ProductsSalesSupportDownloadsAbout |
Home » Technical Support » DBISAM Technical Support » Support Forums » DBISAM Client/Server » View Thread |
Messages 1 to 5 of 5 total |
"Error 10243 Cannot lock the session" error blocking all write access for clients |
Wed, Jan 23 2013 8:48 PM | Permanent Link |
LachlanG | 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 |
Wed, Jan 23 2013 10:56 PM | Permanent Link |
Raul Team Elevate | 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 |
Thu, Jan 24 2013 1:27 AM | Permanent Link |
LachlanG | 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 |
Thu, Jan 24 2013 8:49 AM | Permanent Link |
Tim Young [Elevate Software] Elevate Software, Inc. timyoung@elevatesoft.com | 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 |
Thu, Jan 24 2013 8:51 AM | Permanent Link |
Tim Young [Elevate Software] Elevate Software, Inc. timyoung@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 |
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 |