23 октября, вторник 07:56
Bankir.Ru

Объявление

Свернуть
Пока нет объявлений.

Ctrl-Alt-Q оказалось небезопасным ...

Свернуть
X
  • Фильтр
  • Время
  • Показать
Очистить всё
новые сообщения

  • Ctrl-Alt-Q оказалось небезопасным ...

    Использование всем известное сочетание клавиш (удобный функционал) привело к неприятностям.
    Оказывается, что среди полсотни запросов, идущих от клиента к серверу, оказался запрос типа BEGIN TRAN. Потом еще полсотни, часть которых ставили естественно блокирующие lock-и и, наконец, COMMIT.
    Вроде постулат "Открой транзакцию на сервере и не возвращайся на клиента без ее закрытия" Диасофт решил проигнорировать.
    На рабочей базе это уже стало опасным делать.
    С чего это Диасофт решил так делать ?

  • #2
    Сообщение от AlexanP Посмотреть сообщение
    Вроде постулат "Открой транзакцию на сервере и не возвращайся на клиента без ее закрытия" Диасофт решил проигнорировать.
    Это конкретная ошибка конкретной реализации скриптового перехода. Занесите ошибку - и данный код будет исправлен

    Комментарий


    • #3
      Тогда уж если есть желание прокомментировать, то вот например
      часть кода многих SMF из каталога SCRIPTS

      Это из файла MassRepayment.smf

      function StepBack(){
      try{
      Transaction.Start();

      var PrtID = Accrual.Parameter("DealProtocolID");
      Accrual.DeleteDocuments(PrtID);
      Accrual.DeleteProtocol(PrtID);

      Transaction.Commit();
      }
      catch(e){
      if(Transaction.Trancount!=0) Transaction.Rollback();
      Err.Add("Ошибка при откате начисления. " + e.description);
      }
      }

      Комментарий


      • #4
        Сообщение от AlexanP Посмотреть сообщение
        try{
        Transaction.Start();

        var PrtID = Accrual.Parameter("DealProtocolID");
        Accrual.DeleteDocuments(PrtID);
        Accrual.DeleteProtocol(PrtID);

        Transaction.Commit();
        Ну вообще не так плохо - диалогов с пользователем нет, никаких отчетов и арифметики внутри транзакции не вызывается. Удаление проходит не массово - а только по конкретному договору - значит транзакция короткая. Скорее всего программист рассчитывал метод перетащить Accrual.DeleteDocuments и Accrual.DeleteProtocol исключительно на сервер - да дыхалки не хватило - оставил как есть (наверное внутри кода deal32 на Delphi реализован). Учитывая что код с 2004 г в таком виде живет - наверное проблем у пользователей с ним за 3 года не возникало...

        Комментарий


        • #5
          Ну тогда еще вопрос:
          Почему так много запросов идет к серверу после того, как пользователь (в разных формах) нажал кнопку "Выполнить" ?
          Если после нажатия кнопки нет диалога с пользователем, если он заполнил все поля формы, то зачем клиентская часть посылает серверу десятки, может и сотню запросов ? В "старом" 5НТ были еденицы запросов, но от Ритэйловых модулей впечатление как от Clarion-а.

          Комментарий


          • #6
            Произошел недавно случай. У нескольких пользователей появилось окошечко с сообщенем "Lock time out". Начали смотреть процессы на сервере. Увидели один процесс, блокирующий остальные. Позвонили пользователю и спросили что он делает. Оказалось, что он нормально работает (с вкладами). Т.е. у него открыта транзакция и тем не менее он работает в интерфейсе FA#. Попросили выйти из системы и зайти заново. Блокировки снялись и мы успокоились. Но через 10 мин звонит этот пользователь и КРИЧИТ, что у него пропали документы, которые вроде даже и касса подтвердила. Среди удаленных мы не нашли. Начали думать, что это было и осталась версия, что при выходе из системы открытая транзакция откатилась вместе со всеми документами.
            Тут возникает первый вопрос всегда ли Диасофт ставит SET XACT_ABORT ?
            After SET XACT_ABORT ON is executed, any run-time statement error causes an automatic rollback of the current transaction
            И второй вопрос а могут ли быть такие "run-time statement error", которые завершают batch, но НЕ откатывают транзакцию ?
            Ну например в результате такого "Lock time out".

            Комментарий


            • #7
              Сообщение от AlexanP Посмотреть сообщение
              Ну тогда еще вопрос:
              Почему так много запросов идет к серверу после того, как пользователь (в разных формах) нажал кнопку "Выполнить" ?
              Я уже старался ответить на это в предыдущем письме. Потому что с точки зрения компонентной модели, для бизнес-программиста - каждая функция - это "черный ящик". Ему нет разницы - написан этот код на SQL (в виде хранимой процедуры или select), Delphi (BPL & Co) или JavaScript (SMF Файлы). Поэтому он находит первую попавшуюся реализацию и вставляет ее в бизнес-цепочку. Получается быстро и с максимальным использованием ранее написанного кода. Однако с точки зрения архитектуры - недостатки налицо - та часть, которую было бы интереснее выполнять на сервере - для нее есть только компонента, выполняющаяся только на клиенте (и так далее). Или проблема обработки ошибок - если работает связка из Delphi-Java-SQL - непонятно в какой точке этой "трубы" следует выходить. Поэтому второй частью программирования следовало бы занести требование на перенос указанной компоненты на другой уровень - чего видимо в данной задаче не произошло. В идеале хотелось бы чтобы такой рефакторинг вообще делался бы одним движением мышки - а язык программирования был единый для фронта, миддла и серверной части.
              Но пока подобная платформа рождается в очень больших муках и спорах.

              Комментарий


              • #8
                Сообщение от AlexanP Посмотреть сообщение
                Но через 10 мин звонит этот пользователь и КРИЧИТ, что у него пропали документы, которые вроде даже и касса подтвердила. Среди удаленных мы не нашли.
                Полное безобразие. Надеюсь, вы на этот метод (что КОНКРЕТНО выполнял пользователь во вкладах и где потенциально может быть вываливаение из транзакции) занесли ошибку ?

                Комментарий


                • #9
                  А зачем создаётся транзакция?
                  Она здесь не нужна.
                  Если метод Accrual.DeleteProtocol(PrtID) оставляет после себя документы, то это ошибка.

                  Комментарий


                  • #10
                    Надеюсь, вы на этот метод (что КОНКРЕТНО выполнял пользователь во вкладах и где потенциально может быть вываливаение из транзакции) занесли ошибку ?

                    В Диасофте нам рекомендовали выставить cost threshold for parallelism. А вот что делал пользователь, теперь уже сами жалеем, что не засняли сразу, а попросили выйти из системы.
                    Точно, что делались пополнение вклада и безналичная конвертация там же.
                    Но у меня вопрос был, а может ли быть в MSSQL такое "run-time error" вываливание из транзакции без ее автоматического отката ?

                    Комментарий


                    • #11
                      Сообщение от AlexanP Посмотреть сообщение
                      Надеюсь, вы на этот метод (что КОНКРЕТНО выполнял пользователь во вкладах и где потенциально может быть вываливаение из транзакции) занесли ошибку ?

                      В Диасофте нам рекомендовали выставить cost threshold for parallelism. А вот что делал пользователь, теперь уже сами жалеем, что не засняли сразу, а попросили выйти из системы.
                      Точно, что делались пополнение вклада и безналичная конвертация там же.
                      Настройка стоимости паралелизма влияет только на планы запросов, т.е. на производительность. Для пятерки лучше выставлять её по максимуму.
                      Сообщение от AlexanP Посмотреть сообщение
                      Но у меня вопрос был, а может ли быть в MSSQL такое "run-time error" вываливание из транзакции без ее автоматического отката ?
                      Не совсем понятен вопрос, но возможна такая ситуация.
                      delete tDocMark where SPID = @@spid
                      begin tran
                      save tran Tran1
                      insert tDocMark select @@spid, 1, 2000
                      save tran Tran1
                      insert tDocMark select @@spid, 1, 2000
                      if @@error > 0
                      begin
                      select 'rollback tran'
                      rollback tran Tran1
                      end
                      if @@trancount > 0
                      commit tran
                      go
                      select @@trancount
                      select * from tDocMark where SPID = @@spid

                      Комментарий


                      • #12
                        Не совсем понятен вопрос, но возможна такая ситуация
                        Да нет, другая ситуация, когда сам SQLServer завершает batch (т.е. нет возможности анализировать @@error и делать все остальное) и при этом процесс остается жив на сервере, только транзакция остается открытой. Может я некорректно назвал это "run-time error". Может сообщение с "lock time out" было результатом такого аварийного завершения batcha.

                        Комментарий


                        • #13
                          Если нет кода, который закрывает "чужие" транзакции, а в пятерке такого не наблюдается(что правильно), то открытая транзакция будет висеть до дисконекта. А когда коннект закроется ВСЁ откатится.

                          Комментарий


                          • #14
                            Сообщение от AlexanP Посмотреть сообщение
                            Не совсем понятен вопрос, но возможна такая ситуация
                            Да нет, другая ситуация, когда сам SQLServer завершает batch (т.е. нет возможности анализировать @@error и делать все остальное) и при этом процесс остается жив на сервере, только транзакция остается открытой. Может я некорректно назвал это "run-time error". Может сообщение с "lock time out" было результатом такого аварийного завершения batcha.
                            Time out настраивается в BDE, лучше сразу ставить по нулям. Тогда по time out у вас ниче не отвалится. Хотя это вам решать.

                            Комментарий

                            Пользователи, просматривающие эту тему

                            Свернуть

                            Присутствует 1. Участников: 0, гостей: 1.

                            Обработка...
                            X