![]() | ![]() Products ![]() ![]() ![]() ![]() |
Home » Technical Support » ElevateDB Technical Support » Support Forums » ElevateDB Connectivity » View Thread |
Messages 1 to 3 of 3 total |
![]() |
Sun, Jan 8 2012 8:44 PM | Permanent Link |
David Cornelius Cornelius Concepts | I know some parts of this discussion have been addressed here and there, but
I couldn't find very much--perhaps that is because the documentation is pretty good. I think I have setup the proper parameters but would like to bounce the idea of some of you here. I have a pretty simple situation and figured the defaults were good enough, but now some queries are getting longer and I've been getting complaints of timeouts and see some LogEvents on the server with the message, "The Session ID # is no longer present on the server." So I need to make some changes. The server is running EDB 2.05b10 on a Windows 2008 32-bit server, hosted over the internet. Each of the 6 users of the custom Delphi application (with the EDB components of the same version) is connected remotely from a different location--there is no central office. Here are the Server settings: Session Timeout = 1800 (30 minutes) Dead Session Interval = 300 (5 minutes) Dead Session Expiration = 1800 (30 minutes) Maximum Dead Sessions = 20 Here are the Client settings: Remote Pinging = 45 Remote Timeout = 300 (5 minutes) I've got an OnRemoteTimeout event hooked up to ask if the user wants to try to reconnect if it encountered a timeout. If they answer No, the application terminates. It pings frequently--the session shouldn't die when the user steps away from the computer. (If there were hundreds of users, I probably wouldn't want each one to be pinging that often.) If their internet connection goes down, they have an hour to recover and reconnect before their session is killed on the server (30 minutes before it's considered "dead" and another 30 minutes before the dead session is killed). The client's timeout has been upped from the default of 180 seconds to 300 to be much longer than the longest query should take. Since a test environment doesn't always see the same problems the clients do in production, I first set the parameters really low on the server so it would be easy to get timeouts. Then I upped them to make sure those problems went away. I believe I've resolved the problem, but am wondering if what I've done is too extreme or if there are other issues that might creep in with these values. One other consideration is that some of the users work on laptops and might close the lid to put the computer to sleep, then reopen it later. If they left this application on, and try to reconnect with an hour, it should find the session and reactivate it, right? Is there any problem with upping the Dead Session Expiration to several hours? Any thoughts? David Cornelius Cornelius Concepts |
Tue, Jan 10 2012 4:19 PM | Permanent Link |
Tim Young [Elevate Software] Elevate Software, Inc. ![]() | David,
<< One other consideration is that some of the users work on laptops and might close the lid to put the computer to sleep, then reopen it later. If they left this application on, and try to reconnect with an hour, it should find the session and reactivate it, right? >> Yes, that is correct. << Is there any problem with upping the Dead Session Expiration to several hours? >> Well, the problem with a very long dead session expiration time is the possibility of locks being held for that time period. One can always manually remove sessions in such a case, but it's usually easier to have the EDB Server do it automatically. However, that can clash with the requirement of long-running sessions on the client application that need to reconnect periodically. -- Tim Young Elevate Software www.elevatesoft.com |
Tue, Jan 10 2012 9:06 PM | Permanent Link |
David Cornelius Cornelius Concepts | Thanks for the reply and for confirming my thoughts on the idea.
David Cornelius Cornelius Concepts |
This web page was last updated on Wednesday, August 14, 2024 at 03:12 PM | Privacy Policy![]() © 2024 Elevate Software, Inc. All Rights Reserved Questions or comments ? ![]() |