Подскажите, пожалуйста, что имеется в виду — intentionally random time span?

Почему именно случайно выбранное из диапазона время помогает определить бездействующее подключение. А если бы это было всегда 6 минут, например, то что бы изменилось? Или я не так понимаю смысл вообще?

When a connection is returned to the connection pool, it has a default idle lifetime of four to eight minutes, which is an intentionally random time span to ensure that idle connections are not held indefinitely

Вот здесь подробно объясняется, и откуда взялось от 4 до 8 (7 минут 40 секунд на самом деле), но не понятно, зачем именно случайное. А в той фразе, что мне нужно перевести, упор делается именно на случайное?

Q If an app makes 50 simultaneous connections to SQL Server™, there will be 50 connections in the connection pool. When are they removed from the pool? If their ConnectionLifetime is 0, which the documentation describes as using the maximum connection lifetime, how long is this?

A The logic behind removing connections from the pool is undocumented, but this has not prevented people from trying to discover it and write articles about it. The best one is probably SqlClient Connection Pooling Exposed — Reflection allows .NET developers to peer into the internals of SqlClient . You can also check out the following blog: ADO.NET The misunderstood "Connection Lifetime" managed pooler connection string keyword .

The basic idea is that connections left idle in the pool will be cleared at a random time between approximately four minutes and eight minutes, depending on implementation details. There is nothing that you can do short of using reflection, as shown in the article mentioned previously, to change this default.

The actual behavior for a connection with minimum pool size set is the same as for a connection without it. On closing the connection, the connection lifetime will be checked and it will be disposed. The managed pooler will notice that you have gone under the minimum pool size and it will open a new connection on a background thread. Connection lifetime has nothing to do with the connection pool idle time. Setting it to 0 equals the maximum value of int32.MaxValue, or 2147483647 seconds.

Заранее спасибо

Здравствуйте, <Аноним>, Вы писали:

А>Подскажите, пожалуйста, что имеется в виду — intentionally random time span?

Здесь ты все правильно понял — преднамеренно случайный интервал времени.

А>Почему именно случайно выбранное из диапазона время помогает определить бездействующее подключение.

А вот здесь не так. Как раз смысл предоставленных тобой текстов в том, что на самом деле connection lifetime не имеет никакого отношения к бездействию подключения (да и "преднамеренно случайный" интервал времени оказывается не таким и случайным). Фактически с этим "случайным интервалом времени" сравнивается время соединения, а не время простоя соединения, что приводит к удалению из пула используемых соединений. Это может быть полезно при выравнивании нагрузки в кластере, но малоосмысленно для одиночного сервера.

А вот зачем эти "танцы с бубном", увы, вопрос не ко мне:

А> но не понятно, зачем именно случайное
А> А если бы это было всегда 6 минут, например, то что бы изменилось?
Не знаю. С моей точки зрения при описываемом поведении даже постоянная величина connection lifetime не приведет к единственному вроде бы потенциально негативному результату — учащению одновременного массового удаления из пула множества соединений. Но это только очень маленькое imho.

Но это вопрос для другого форума...

Здравствуйте, Alex Reyst, Вы писали:

А>> но не понятно, зачем именно случайное
А>> А если бы это было всегда 6 минут, например, то что бы изменилось?
AR>Не знаю. С моей точки зрения при описываемом поведении даже постоянная величина connection lifetime не приведет к единственному вроде бы потенциально негативному результату — учащению одновременного массового удаления из пула множества соединений. Но это только очень маленькое imho.

AR>Но это вопрос для другого форума...

Да, большое спасибо, попробую в базах данных спросить, тем более, что отсюда все равно вычеркнули.

Здравствуйте, <Аноним>, Вы писали:

А> тем более, что отсюда все равно вычеркнули.

Не вычеркнули, а как раз и попросили перенести в БД.