Фил а что не так с обычной транзакцией в базе даных ?

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

Фил а что не так с обычной транзакцией в базе даных ?

Она может быть долгой

И что делать, когда захочется немонетарных балансов?

Внедрение любого биллинга начинается с ответов на четкие вопросы: "что конкретно и каким образом ты хочешь считать". Ты сначала на эти вопросы ответь.

Когечно они есть. Я хочу иметь лог проводок. Считать что и как - дело конкретного сервиса или их комьинациио которой знают они, поддержтвпют они, и виноваты они

Когечно они есть. Я хочу иметь лог проводок. Считать что и как - дело конкретного сервиса или их комьинациио которой знают они, поддержтвпют они, и виноваты они

я хочу иметь исчерпывающий. лог сделок и проводок. и интерфейс к ним. все

Типа "внеси на счет 5к руб и получи 5 доменов в подарок"

Типа "внеси на счет 5к руб и получи 5 доменов в подарок"

тип того. долгая хрен с ним - так не бывает у меня.но сложная

Ну или "домен к хостингу в подарок"

И проч

я не предлагаю select for update

я предлагаю трназакцию

неужели в муське нет транзакций ?

с нормальным rollback ? и commit

http://dev.mysql.com/doc/refman/5.7/en/commit.html

нет все в порядке трнзакции есть

я помню что там какая то беда была с изоляцией транзакций, типа гразные данные видать

но уровнем изоляции это решается вполне

а может у тя просто автокоммит включен ?

или у тя Myisam для биллинговых данных ???????????????

Фил, мой ресурс конечен. Тебе уже несколько человек описали что и как.

Я тебе даже упрощу. Есть User1 с 1$ на лицевом счету и работающей услугой VDS1за 4 бакса в месяц. Через три недели он захотел поменять услугу VDS1 на услугу VDS2 стоимостью 8 баксов в месяц. Давай это действие смены тарифа по шагам пройдем. Шаг - транзакция БД. Выключаем каждый и каждыей междушаг электричество. Как пинг. Смотрим размер фарша в моём варианте записи этих шагов и в твоем варианте забивания на запись.

я не предлагаю select for update

предлагаешь. потому что мне нужно залочить услуги, счета, проводки, метаинформацию

нет

транзакця это делает за тебя

коечно нет

или ты предлагаешь сериализованную изоляцию? да, уже предлагали

я предлагаю не read commited да.

как минимум репитабл рид

Т.е. при любом фейле (а они будут постоянно в виду особенности уровня изоляции) - вздрочнуть ещё раз? ну вариант да.

как минимум репитабл рид

а в этом селект фор аплейт - куда ты от него денешься?

да при чем тут селект фор апдейт.

а как ?

селект форапдейт это псевдо трнзакция для простых вещей

это псевдотранзакция для блокировки данных

да

которая является упрощением от нормальной трнзакции

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

ну

бегин сделал. селект первый сделал, все данные в пределах трнзакции неизменны.

ну мне не понравилось десятиэтажные селекты фор апдейты составлять

пока комимт или ролбек не сделаешь повтор чтения будет давать такие же результаты

селект форапдейты для простых случаев.

мля

пофиг что тут про постгрес. в муське так же

мы на разных языках?

https://www.youtube.com/watch?v=QU2PVSnBGEY&list=PLaFqU3KCWw6JgufXBiW4dEB2-tDpmOXPH&index=2

как я не заблокирую данные-то?

мне нужно заблокировать всё, что я потом апдейтить буду. или кто-то туда писнет без меня

еще раз. не смотри что тут про постгрес говорят.

да причем тут постгресс

в рамках транзакции никто ничего не пихнет

в рамках нет. а за рамками да

а за рамками транзакции нет операций со счетом

а у меня два десятка sum = sum +1

когда коммит проходит если строки были изменены которые менялись в транзакции комит непроходит

проходит ролбек

ладно баиньки

когда коммит проходит если строки были изменены которые менялись в транзакции комит непроходит

ну это Serializable. это вариант. но плохой

ну мне не нра

когда коммит проходит если строки были изменены которые менялись в транзакции комит непроходит

это называется однопоточный билинг, что имеет место быть, но и имеет свои геморы и весьма ощутимые

У меня один вопрос: что будет если я из разных вкладок попытаюсь сменить тариф на разные тарифы

У меня один вопрос: что будет если я из разных вкладок попытаюсь сменить тариф на разные тарифы

это был мой вопрос к тебе кстати. вот что будет?

У меня один вопрос: что будет если я из разных вкладок попытаюсь сменить тариф на разные тарифы

кстати, это у меня по сей день и в петерзосте до прошлого года превращало финансовые данные в фарш

но моя текущая система очень бедная и попасть между запросами надо было ещё умудриться :)))

но умудрялись

правда в ПХ теперь как в DO - мозг можно сломать пытаясь понять кто кому должен

ERROR: S client not available

Резервирование средств должно ставить эксклюзивный лок. Чтобы оно проходило всегда консистентно

Фил, блин, в твоём примитивном билинге, нужна единственная таблица "очередь", с тем что надо списать/зачислить и один воркер её разгребающий, причём ни чего из неё не удаляющий, а только апдейтящий поля состояния задания. В чём гемор-то?

А дальше, мы создаем операцию, которая в процессе - изменение тарифа. Двух параллельных изменений быть не может. Все из выполняем по очереди. А очередь ставим из чего во что мы хотим поменять. Если к началу операции "из чего" поменялось - откат.

Optimistic transactions

Фил, блин, в твоём примитивном билинге, нужна единственная таблица "очередь", с тем что надо списать/зачислить и один воркер её разгребающий, причём ни чего из неё не удаляющий, а только апдейтящий поля состояния задания. В чём гемор-то?

Псссс... не мешай цветению перфекционизма ;)

Резервирование средств должно ставить эксклюзивный лок. Чтобы оно проходило всегда консистентно

да шут с ним с резервированием. это хорошая тема. но она чуть в стороне. смотри. есть сделки и деньги. сделка это наши финансовые отношения с клиентом. например заказ 555 с 01:00 по 12:00. есть услуги. это например контейнер C1 с такими-то характеристиками. вся суть бугурта - способ связать в одну бизнестранзакцию создание/изменение услуги C1 и вот той денежной части

Фил, блин, в твоём примитивном билинге, нужна единственная таблица "очередь", с тем что надо списать/зачислить и один воркер её разгребающий, причём ни чего из неё не удаляющий, а только апдейтящий поля состояния задания. В чём гемор-то?

Ну примерно. Только вот читай выше мой предыдущий коммент про откат

Фил, блин, в твоём примитивном билинге, нужна единственная таблица "очередь", с тем что надо списать/зачислить и один воркер её разгребающий, причём ни чего из неё не удаляющий, а только апдейтящий поля состояния задания. В чём гемор-то?

ммм... а я как сказал?

А дальше, мы создаем операцию, которая в процессе - изменение тарифа. Двух параллельных изменений быть не может. Все из выполняем по очереди. А очередь ставим из чего во что мы хотим поменять. Если к началу операции "из чего" поменялось - откат.

Ну. Так это мое предложение.

Ну так заканчивает этот многогодовалый флуд и сделай уже все "свои предложения"

А дальше, мы создаем операцию, которая в процессе - изменение тарифа. Двух параллельных изменений быть не может. Все из выполняем по очереди. А очередь ставим из чего во что мы хотим поменять. Если к началу операции "из чего" поменялось - откат.

причем, если очередь сделать последовательной например пер кастомер, то у нас количество паттернов, когда надо делать откат резко уменьшается почти до 0

одна "очередь", зачем per customer? Задачи и так не пересекающиеся

Ну так заканчивает этот многогодовалый флуд и сделай уже все "свои предложения"

так началось с того, что я спросил "есть чо" по поводу очередей :))))))) в pgsql есть в новейшей версии select ... skip locking for update limit 0,1

одна "очередь", зачем per customer? Задачи и так не пересекающиеся

а потому что тогда можно параллельно кастомеров обрабатывать. но в моём случае можно и просто последовательно конечно

Резервирование средств должно ставить эксклюзивный лок. Чтобы оно проходило всегда консистентно

на языке Фила это select for update

так началось с того, что я спросил "есть чо" по поводу очередей :))))))) в pgsql есть в новейшей версии select ... skip locking for update limit 0,1

9.5 не самая новая

я так понимаю 9.6 ещё побаиваются

у меня 9.5, тысячи транзакций в секунду в пике , полёт нормальный

да 9.5 уже в хвост и грву да

вон, тезка мне собственно подкинул идею с какой-то платежной системы как раз про очереди в pgsql

Ну так заканчивает этот многогодовалый флуд и сделай уже все "свои предложения"

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

на языке Фила это select for update

на моём языке это тоже эксклюзивная блокировка. не заражайся говном от Сереги - дураков кроме него сюда не завезли. но мы там где-то уже про транзакции в базе говорили. а это ведь всегда SQL в данном типе задач. или есть мнение, что есть не реляционные базы под это (точнее есть какая-то нереляционная перспективная модель данных для биллинга? я с удовольствием почитаю) подходящие? или есть мнение, что есть какие-то не SQL реляционные базы, которые имеет смысл использовать?

есть NewSQL

есть NewSQL

The applications targeted by these NewSQL systems are characterized as having a large number of transactions that (1) are short-lived как раз то, что щорсу не надо...

длинные транзакции немного про другое, типа аналитики

есть NewSQL

Ну они пока есть только в мечтах. Или экспериментах. Кстати спасибо. Не знал о таком

VoltDB — очень интерпрайзная штука

длинные транзакции немного про другое, типа аналитики

Да не нужны мне длинные транзакции. Я не очень понимаю, чего вы не понимаете. Проблема в кодогенерации. Надо генерировать достаточно сложный запрос для эксклюзивной блокировки тех данных, которые меняем. Да, можно использовать какой-нибудь из объектов как абсолютный признак эксклюзивной блокировки - там лицевой счет, или вот резервированные деньги, как предлагал Сергей, но что-то меня смущает в этом. Поменяется где-то логика, а у меня вся консистентность завязана на конкретном объекте

VoltDB — очень интерпрайзная штука

С особенностью. in-memory

Да не нужны мне длинные транзакции. Я не очень понимаю, чего вы не понимаете. Проблема в кодогенерации. Надо генерировать достаточно сложный запрос для эксклюзивной блокировки тех данных, которые меняем. Да, можно использовать какой-нибудь из объектов как абсолютный признак эксклюзивной блокировки - там лицевой счет, или вот резервированные деньги, как предлагал Сергей, но что-то меня смущает в этом. Поменяется где-то логика, а у меня вся консистентность завязана на конкретном объекте

Так вся проблема как раз в том, что у тебя что-то на что-то завязано так как ты когда-то давно по дурости решил. А теперь ты стремаешься каких-то очевидных решений. И ещё не понимаю твою паранойю по поводу возможного "мусора", который "надо собирать", в чём проблема-то?

http://izvestia.ru/news/601535

любители шутить про гитлера в чятике?