Icon View Thread

The following is the text of the current message along with any replies.
Messages 11 to 15 of 15 total
Thread Disconnected sessions not being removed
Mon, Jan 30 2017 3:03 PMPermanent Link

Tim Young [Elevate Software]

Elevate Software, Inc.

Avatar

Email 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 AMPermanent 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 PMPermanent 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 AMPermanent Link

Tim Young [Elevate Software]

Elevate Software, Inc.

Avatar

Email 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 PMPermanent 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 PagePage 2 of 2
Jump to Page:  1 2
Image