The Query Sessions throttle limits the non-utility sessions that can log on at the same time. The Query Sessions throttle can only reject sessions trying to log on; it cannot delay session logons. Once TASM rejects a throttled session, the user has to log on again.
The Query Sessions throttle can use only source classification criteria. For example, it can include account names, profiles, or IP addresses. It may not include target criteria, such as a database name or table name.
- Provides the least granular control. TASM treats all requests that qualify for this throttle as one group. If the requests are delayed, the delay is based on the concurrency level of the entire group. For example, users Jay, Kay, and May are the classification criteria for a system throttle rule with a limit of 3 requests. With the collective option, all the users together cannot have more than 3 requests running at the same time.
- Each individual object that is associated with the throttle is treated independently of other, similar objects. Each object has a counter. For example, if users Jay, Kay, and May are the classification for a throttle rule with a limit of 3 requests, each of the users can have up to 3 requests running at the same time.
- Provides the most fine control. TASM treats each user in a throttled object (such as account) independently of other users in that account. The intent of the Member option is to enable objects that represent groups of users, such as accounts and profiles, to be used as the classification criteria for the rule. The rule specifies the group, and any member of the group is covered by the rule. For example, users Jay, Kay, and May are associated with account ShoeDept. If there is a system throttle rule with a session limit of 3, classification criteria of account ShoeDept, and the Member option, then each of the users with the ShoeDept account can have up to 3 requests running at the same time.