Login ProductsSalesSupportDownloadsAbout |
Home » Technical Support » DBISAM Technical Support » Support Forums » DBISAM Client/Server » View Thread |
Messages 11 to 15 of 15 total |
Disconnected sessions not being removed |
Mon, Jan 30 2017 3:03 PM | Permanent Link |
Tim Young [Elevate Software] Elevate Software, Inc. timyoung@elevatesoft.com | Graham,
<< They do seem like they are being removed after an hour or so, i dont think from memory they are hanging around longer than that. I have changed the dead session clean up times to be 10 seconds to timeout and 30seconds on clean up, in case there is a timing issue there. >> Hmm, that's really odd. Is it possible that you've got any DBISAM calls that are taking a really long time to complete ? What I'm thinking of is a situation where you're calling a server-side procedure or something else that may "hang" waiting on some other process. Or, similarly, have you customized the DBISAM Database Server at all, adding any custom code that may interfere with the normal operation of the server ? The reason why this is odd is that any session that completes an API call will naturally be subject to the server-side timeout, and will no longer be locked. Thus, the dead session handling will both be able to a) detect when the session is actually disconnected, and b) not have any issues obtaining a lock on the server session in order to remove it permanently. Tim Young Elevate Software www.elevatesoft.com |
Thu, Feb 2 2017 12:45 AM | Permanent Link |
Graham Mylne | Im trying to investigate any long calls we may have. i did have a client for some reason make a call that held a transaction for 10mins not sure why, they then forced the application to close by continuously clicking the red X. They do seem to have a really slow internet too, which im not sure if that is going to cause any problems too.
We have made changes to the source for the DBISAM server, i will look over the changes, they generally relate to triggers and there is a call in there for a custom procedure. This does not seem to happen with all of our clients just these guys are repeat offenders which is odd too. |
Mon, Mar 13 2017 8:58 PM | Permanent Link |
Graham Mylne | So I updated the server side with a new version of DBISAM server, removed all of our server side code except one procedure which is to execute SQLs from the client.
In the server log, this looks to be where the server stopped responding to transactions, the clients were waiting for 20+ minutes before we restarted it to keep them moving along. 14/03/2017 9:29:59 AM Restricted transaction started [Client Version: 4.36 User Name: admin Address: 192.168.1.110 Encrypted: No Request: REQUEST_STARTTRANS Thread: 6616 Session: 9] 14/03/2017 9:29:59 AM Connection closed [Client Version: 4.36 User Name: admin Address: 192.168.1.110 Encrypted: No Thread: 6616 Session: 9] 14/03/2017 9:29:59 AM Re-connection accepted [Client Version: 4.36 User Name: admin Address: 192.168.1.110 Encrypted: No Thread: 9672 Session: 9] 14/03/2017 9:29:59 AM Connection closed [Client Version: 4.36 User Name: admin Address: 192.168.1.110 Encrypted: No Thread: 9672 Session: 9] |
Thu, Mar 16 2017 8:23 AM | Permanent Link |
Tim Young [Elevate Software] Elevate Software, Inc. timyoung@elevatesoft.com | Graham,
<< So I updated the server side with a new version of DBISAM server, removed all of our server side code except one procedure which is to execute SQLs from the client. In the server log, this looks to be where the server stopped responding to transactions, the clients were waiting for 20+ minutes before we restarted it to keep them moving along. >> That doesn't look right. A transaction started by a server-side procedure shouldn't cause a logged Start Transaction call in the database server log. Only a remote session connected from a client application should cause that. Can you email me this server-side procedure source code ? Thanks, Tim Young Elevate Software www.elevatesoft.com |
Thu, Mar 16 2017 6:27 PM | Permanent Link |
Graham Mylne | Tim Young [Elevate Software] wrote:
Graham, << So I updated the server side with a new version of DBISAM server, removed all of our server side code except one procedure which is to execute SQLs from the client. In the server log, this looks to be where the server stopped responding to transactions, the clients were waiting for 20+ minutes before we restarted it to keep them moving along. >> That doesn't look right. A transaction started by a server-side procedure shouldn't cause a logged Start Transaction call in the database server log. Only a remote session connected from a client application should cause that. Can you email me this server-side procedure source code ? Thanks, Tim Young Elevate Software www.elevatesoft.com Will do it now. |
« Previous Page | Page 2 of 2 | |
Jump to Page: 1 2 |
This web page was last updated on Tuesday, September 17, 2024 at 04:19 AM | Privacy PolicySite Map © 2024 Elevate Software, Inc. All Rights Reserved Questions or comments ? E-mail us at info@elevatesoft.com |