Difference between revisions of "Allscripts Enterprise EHR Session Timeouts"
(New page: '''Information on Timeouts''' There are two types of timeouts in the IDX Web Framework – Session Timeout and Session Pause Timeout. Session Timeout defines the number of minutes of inac...) |
|||
| Line 1: | Line 1: | ||
'''Information on Timeouts''' | '''Information on Timeouts''' | ||
| + | |||
There are two types of timeouts in the IDX Web Framework – Session Timeout and Session Pause Timeout. Session Timeout defines the number of minutes of inactivity until the user is logged out. When the user is logged out, all unsaved data will be saved. For example, a note that was created and data entered will be saved as the user is logged out. Session Pause Timeout defines the number of minutes of inactivity until the session is paused / locked. | There are two types of timeouts in the IDX Web Framework – Session Timeout and Session Pause Timeout. Session Timeout defines the number of minutes of inactivity until the user is logged out. When the user is logged out, all unsaved data will be saved. For example, a note that was created and data entered will be saved as the user is logged out. Session Pause Timeout defines the number of minutes of inactivity until the session is paused / locked. | ||
'''Impact of Locking a session and Session Timeout''' | '''Impact of Locking a session and Session Timeout''' | ||
| + | |||
The following is based on my experience in one client’s production system. It appears as though the Session Timeout will be based on the time the user locked the session. I also noticed that the timeout was effectively doubled once the session was locked. Here’s an example. The system is set to timeout after 30 minutes of inactivity. Normally the user is logged out 30 minutes since their last activity in TouchWorks – “activity” means making some request to the web server, whether it means navigating to a new page or saving something in the chart. Let’s say the user locks their session 15 minutes after their last “activity”. They won’t be logged out until 60 minutes later, or 75 minutes since their last request to the web server. | The following is based on my experience in one client’s production system. It appears as though the Session Timeout will be based on the time the user locked the session. I also noticed that the timeout was effectively doubled once the session was locked. Here’s an example. The system is set to timeout after 30 minutes of inactivity. Normally the user is logged out 30 minutes since their last activity in TouchWorks – “activity” means making some request to the web server, whether it means navigating to a new page or saving something in the chart. Let’s say the user locks their session 15 minutes after their last “activity”. They won’t be logged out until 60 minutes later, or 75 minutes since their last request to the web server. | ||
'''Impact on Load Balancing''' | '''Impact on Load Balancing''' | ||
| + | |||
The above has an impact on the timeouts for load balancing. Without knowing this, it would make sense to setup a load balancer with sticky sessions to have a timeout of a value greater, and usually just a little bit greater, than the TouchWorks timeout – say 35 minutes if the timeout in TouchWorks is 30. The above scenario demonstrates that 35 minutes is far from sufficient – it should be greater than 90. In short, '''a load balancer should have a timeout of greater than 3x the timeout for TouchWorks.''' | The above has an impact on the timeouts for load balancing. Without knowing this, it would make sense to setup a load balancer with sticky sessions to have a timeout of a value greater, and usually just a little bit greater, than the TouchWorks timeout – say 35 minutes if the timeout in TouchWorks is 30. The above scenario demonstrates that 35 minutes is far from sufficient – it should be greater than 90. In short, '''a load balancer should have a timeout of greater than 3x the timeout for TouchWorks.''' | ||
Revision as of 13:41, 25 July 2007
Information on Timeouts
There are two types of timeouts in the IDX Web Framework – Session Timeout and Session Pause Timeout. Session Timeout defines the number of minutes of inactivity until the user is logged out. When the user is logged out, all unsaved data will be saved. For example, a note that was created and data entered will be saved as the user is logged out. Session Pause Timeout defines the number of minutes of inactivity until the session is paused / locked.
Impact of Locking a session and Session Timeout
The following is based on my experience in one client’s production system. It appears as though the Session Timeout will be based on the time the user locked the session. I also noticed that the timeout was effectively doubled once the session was locked. Here’s an example. The system is set to timeout after 30 minutes of inactivity. Normally the user is logged out 30 minutes since their last activity in TouchWorks – “activity” means making some request to the web server, whether it means navigating to a new page or saving something in the chart. Let’s say the user locks their session 15 minutes after their last “activity”. They won’t be logged out until 60 minutes later, or 75 minutes since their last request to the web server.
Impact on Load Balancing
The above has an impact on the timeouts for load balancing. Without knowing this, it would make sense to setup a load balancer with sticky sessions to have a timeout of a value greater, and usually just a little bit greater, than the TouchWorks timeout – say 35 minutes if the timeout in TouchWorks is 30. The above scenario demonstrates that 35 minutes is far from sufficient – it should be greater than 90. In short, a load balancer should have a timeout of greater than 3x the timeout for TouchWorks.