utm и платежи

[Gezm0]

Насчёт дампа базы не очень понял.

Может потребоваться в процессе диагностики. Особенно если используются платежные системы.

К сожалению дамп базы и обороты по 51 счету предоставить не могу. По понятным причинам.

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

Все ваши мысли на предмет несовершенства ПО понятны и правильны. Разработчиков я не ругаю. Очевидно, вы меня с кем-то перепутали. Однако, в нашу задачу не входит убеждать вас в наличии проблемы. Тем более что результат, как показывает даже наша практика, будет в отсутствии результата. Лучше мы как-нибудь сами костылики напишем, быстрее будет и надёжней. Спасибо за сотрудничество.

[Lex]

Все ваши мысли на предмет несовершенства ПО понятны и правильны. Разработчиков я не ругаю. Очевидно, вы меня с кем-то перепутали. Однако, в нашу задачу не входит убеждать вас в наличии проблемы. Тем более что результат, как показывает даже наша практика, будет в отсутствии результата. Лучше мы как-нибудь сами костылики напишем, быстрее будет и надёжней. Спасибо за сотрудничество.

В наших же интересах проблему исправить. Однако для того чтобы её исправить, её нужно воспроизвести. Если проблема у нас не воспроизводится, вероятность её решения близка к нулю.
Костыли это замечательно, но не факт что они проблему решат.
Если будет желание всё-таки исправить причину проблемы - обращайтесь.

[Pulse]

недавно обнаружил задваивание через платёжные системы... проблема была в битых таблицах, почему они побились выяснить не удалось... или падающий каждые 15 минут RC2 тому виной был или вспышки на Арктуре, выяснить не удалось.... Но почему ядро работало с битыми таблицами непонятно...

[Martin]

Соглашение о конфиденциальности подписывается легко - нужно просто обратиться в отдел продаж.

Это чтобы они данные не продали? ))

[gravis]

О каком модуле в данном случае идет речь? Об утилите utm5_payment_tool?

Какая разница? Платеж можно провести и utm5_payment_tool и через urfa*. Проблема не в этой части!

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

Я вам по полочкам все разложил. Если вы до сих пор не поняли в чем проблема - у вас есть клиенты с этой проблемой. Многие просто еще не заметили что у них платежи от терминалов задупленые (а то и замноженые).

PS. Тут кстати дело не только в банальной загруженности БД, у нас сервер с БД лежит на спинке и лениво крутит вентилятор, но проблема все же была. Искать конкретную причину обсуждаемого бага у меня нет желания, потому что алгоритм приема платажей был изначально неверен и подвержен багам.

[Lex]

О каком модуле в данном случае идет речь? Об утилите utm5_payment_tool?

Какая разница? Платеж можно провести и utm5_payment_tool и через urfa*. Проблема не в этой части!

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

Я вам по полочкам все разложил. Если вы до сих пор не поняли в чем проблема - у вас есть клиенты с этой проблемой. Многие просто еще не заметили что у них платежи от терминалов задупленые (а то и замноженые).

PS. Тут кстати дело не только в банальной загруженности БД, у нас сервер с БД лежит на спинке и лениво крутит вентилятор, но проблема все же была. Искать конкретную причину обсуждаемого бага у меня нет желания, потому что алгоритм приема платажей был изначально неверен и подвержен багам.

Если честно, я не до конца понял что именно происходит. Если платеж вносится через utm5_payment_tool, то какой код возврата возвращает утилита? Если через непосредственный вызов URFA-функции, то какая функция вызывается и что она возвращает?
В любом случае, платеж будет заноситься два раза, если два раза вызывать функцию или запускать утилиту. Платежные системы такого делать не должны если предыдущее внесение платежа выполнилось успешно или ещё не закончилось.

[gravis]

В любом случае, платеж будет заноситься два раза, если два раза вызывать функцию или запускать утилиту. Платежные системы такого делать не должны если предыдущее внесение платежа выполнилось успешно или ещё не закончилось.

В том-то и дело что вызовы на внесение платежей где-то скапливаются. Вариант мне представляется такой:

Висят в памяти и ждут ответа от БД CGI скрипты приема запросов от сервера платежной системы. В этой ситуации сервер платежной системы не получит вообще никакого ответа от скрипта и HTTP/HTTPS сессия отвалится по таймауту. Пока "висит" один, сервер платежной системы делает повторный запрос на проведение платежа, и этим запускает еще один и еще один. А потом в один момент база "отвисает" и все копии скрипта получают почти разом ответ что такого платежа еще не проводилось и запускают utm5_payment_tool.

[UNKNOWN]

Похоже, что проблема все-таки в скрипте, который вы написали.

utm5_payment_tool не проверяет уникальный номер транзакции платежа, поэтому если вам придет одновременно 2 одинаковых http запроса и вы вызовите в 2 разных потоках utm5_payment_tool, то у вас задублируется платеж. utm5 в этом не виновата.

Нетаповские модули платежных систем, кстати, этот момент учитывают.

[Wishmaster]

Пользуюсь модулем платежных систем от Нетап. Проблем с задваиванием или затраиванием платежей нет. (используем Е-порт и Киви). Логика работы в этом модуле как раз правильная. Платежи заносятся в некий буфер, а потом раз в определенный промежуток заносятся в БД. Причем, имеется проблема с периодическим падением самого модуля платежных систем (Когда ж нетап, наконец, сделает его под Freebsd7). Так вот, в случае падения, если платеж в БД был занесен, а платежная система присылает его еще раз, модуль дает отказ на проведение платежа. И это красиво отображается в логах.

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

P.S. Только что увидел, что дистриб, оказывается, обновился. Странно, что не было новостей об этом. Поставил, поглядим, возможно проблема с падениями устранена.

[gravis]

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