Супермаг тормозит на функции supermag.core.NewSession : Супермаг Плюс (Супермаг 2000)

протоколы, нормальное разрешение имен, несколько ключей на сервере лицензий? проблема в хосте, скорее всего... я не исключаю, что накосячил и в самой БД что-то, но из того, что я встречал, чаще всего была проблема в хосте, где работал сервер приложений.

Дело в том что это трайсы, которые показывают соединение локального клиента с СМ. Супермаг на клиенте САМ принимает решение о запуске процедуры supermag.core.NewSession, значит дело не в сервере лицензий и его коннекте с БД. А вот почему такое решение принимается не могу понять. Может СМ оценивает качество связи?

Попробовал на 1000Мб сети региона№2 - supermag.core.NewSession НЕТ.
Попробовал на сервере Windows XP региона№2 - supermag.core.NewSession НЕТ.

То есть от скорости сетки и типа операционной системы сервера лицензий этот реконнект не зависит.

Еще есть какие нибудь соображения?

Физических ключей на сервере лицензий 1, для чистоты эксперемента SQLNET.ORA на серверах убрал, остались только TNSNAMES.ORA.
Все одинаково...результат разный...причем во всем №1 реконнект идет, во всем регионе №2 не идет.
ДУмаю все таки что - то внутри базы, какой то параметр. Но я сравнил таблицу supermag.sssysinfo в обоих регионах и разницы не выявил, которая бы явно была подозрительной.

Вообщем пока состояние прострации...

Параметры БД в Администраторе сервера приложений тоже совпадают???

У меня есть некая уверенность, что ты просто не ловишь сессию с newsession. Кроме того, предлагаю разврапить newsession и посмотреть, есть предположение, что эта процедура дергает ключ, а, соответственно, заставляет работать сервер лицензий, что ты не видишь, отслеживая только одну клиентскую сессию.

Почти все, разница в 5 параметрах, сверялся прямо в таблице sssysinfo. Различные параметры это параметры выгрузки из СМ в УКМ. У меня эта выгрузка везде в кассовых модулях отключена(в обоих регионах), поскольку кассы использую 1С Штрих 1.10, 1С Штрих 5, ДЭНСИ и соотвественно загрузчик их свой.
То есть упрощенно считаем что параметры идентичны.

Я тоже сначала так думал, но эксперемент проводил в регионе №2 (трассировал флекстракером) на 3 компах (два раза на клиентских и 1 раз прямо на сервере запускал СМ и трассировал его, чтобы исключить влияние сети), причем ораклы тоже были разные и на линуксе и на винде. И во всех случаях в регионе №2 нет NewSession.
В регионе №1 точно такие же эксперементы ловят двойной запуск этой процедуры.
Эта процедура запускается не только на переходе на вкладку "Цены", но и при открытии Разделы-Карточки товаров, при переходе на вкладку "Документы"...Вот что еще напрягает. И из за этого происходят торможения. Если нужно могу выложить лог трейса в HTML, там есть время действия каждой процедуры.
Это сделал первым делом, глянул, за время работы данной процедуры производится около 4 запросов к таблице SSLOCKS, видимо на ней и тормоза, проверил все индексы, ключи, в обоих регионах структура таблицы совпадает.

Выложи разврапленый код, посмотрим. Вручную запускать процедуру пробовал?

Да не хотел бы. Все таки интеллектуальная собственность С+. Раз врапят то могут и привлечь. Не стоит, наверное (
Я конечно не юрист, но что-то мне подсказывает что нельзя выкладывать их коды.

Я не про sssysinfo, а про параметры БД Администратора сервера приложений.
Это немного разные вещи.

Если открыть Администратора СМ и сравнить все параметры? Я так тоже сверял оба региона. Но различие только в настройках выгрузки данных.
Ну и задания разные немного (оракловые events), например расчет среднсуточной в регионе №1 нормально делается, в регионе №2 базы больше и расчет сср часто несрабатывает, поэтому там оно отключено..Но это не принципиально...Проблема в чем то другом..