Цитата:
Сообщение от
S.Kuskov
Спасибо за помощь.
Поковырялся - у нас все оказалось немного по другому.
Пример не такой как у чехов а с точностью до наоборот.
У них серверный метод дергает клиентский код, который возвращает forupdate курсор.
У нас клиентский метод дергает серверный код который возвращает forupdate курсор (получен при помощи insert() ).
Ваш способ помог, но не совсем. Вызов .SelectForUpdate(false) после того как курсор вставили и еще и обновили не сбрасывает его свойство selectforupdate - пришлось возвращать дубликат курсора вызовом data()
Потом, посмотрел получше и вообще избавился от предшествующих клиент-серверных вызовов и это тоже помогло !
Т.е. изначально работало так :
Клиентский класс дергает серверный статический метод, который внутри себя создает шапку документа и его строки и по мере заполнения строк делает кучу клиентских вызовов к классу wmsTransportInvoiceReport_RU (он, зараза, клиентским оказался), а в конце возвращает созданную шапку.
Мне показалось странным что глюк от этого возник, т.к. сценарий когда из клиентского кода дергают серверный код, который создает запись и возвращает ее - используется сплошь и рядом. Должна была быть еще какая-то причина возникновения бага.
Если же класс wmsTransportInvoiceReport_RU сделать called from, т.е. убрать в процессе заполнения множество клиент-серверных вызовов, то тоже глюк пропадает сам по себе. Видимо эти множественные клиент-серверные вызовы что-то после себя оставляют, что потом и приводит к появлению глюка. Вполне возможно что после выхода из статического метода синхронный сборщик мусора пытается наконец все почистить пробегаясь по куче ссылок на клиенте и сервере и это приводит к проблемам.
Т.е. нахождение объектов на разных tier однозначное зло. И за классами надо внимательнее смотреть куда они приписаны - called from, client или server