пошел легкий запах CORBA!

Корба как концепт кстати классная вещь. Причем есть места где до сих пор работает)

Корба как концепт кстати классная вещь. Причем есть места где до сих пор работает)

согласен. проверенная вещь, всем рекомендую.

Возьми Apache ignite, Сбербанк на нем работает. Думаю и на твои масштабы получиться натянуть.

Так это же просто in memory cache Разве нет?

это уже кривая архитектура, имхо. может быть не надо в один модуль столько функционала пихать ?

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

Так это же просто in memory cache Разве нет?

Распределенный in memmory

согласен. проверенная вещь, всем рекомендую.

Ну зря сарказм) это большая сложная штука. И многие из идей оттуда просачиваются

Redis тогда уж можно взять

всяко проще нежели игнайт

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

блять от флинка аж затрясло

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

Какую бд тогда лучше выбрать?

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

Распределенный in memmory

о, вспомнил hazelcast

neo4j

о, вспомнил hazelcast

еще есть кохеренс. и инфиниспан. я вообще много слов страшных знаю

или microsoft access

или microsoft access

Foxpro

или microsoft access

наконец-то нормальные советы пошли

Кстати, infinispan, вроде как в acid умеет плюс кластеризуется

Но это опять же кэш, а не субд

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

о, вспомнил hazelcast

вы в bullshit bingo играете?

Но перевод на другую СУБД достаточно проблематично выйдет Крайний случай

зачем вообще тут монгу взяли, какие у нее преимущества в решении задачи построения платежной системы ?

монга для постороения платежной системы

зачем вообще тут монгу взяли, какие у нее преимущества в решении задачи построения платежной системы ?

Скажу честно, этот выбор не я делал Мне сказали, будем на этом работать - приходится

Если я правильно понял, там отталкивались от приемуществ noSql

хорошие у вас архитекторы и обоснования выбора решений интересные.

Что есть, то есть

Так это же просто in memory cache Разве нет?

Ну а hashmap это ведь тоже кеш. Игнат распределённый и есть ACID. Ты тестовое делаешь или это продакшн?

Прод

Прод

Зря вы монгу тащите. Вот тебе нужно записать транзакцию (списали или добавили) и возможно где-то изменить остаток на счету. Без транзакций на уровне БД ты этого не сделаешь, т.к. записать нужно в две таблицы. В монге атомарность только на документе. Нет гарантии, что два документа будут записаны.

Поэтому там совсем по другому мыслят. Нужно уметь работать с eventual consistency.

Зря вы монгу тащите. Вот тебе нужно записать транзакцию (списали или добавили) и возможно где-то изменить остаток на счету. Без транзакций на уровне БД ты этого не сделаешь, т.к. записать нужно в две таблицы. В монге атомарность только на документе. Нет гарантии, что два документа будут записаны.

надо просто будет всех клиентов запихнуть в один документ. ba-dum-tsss!

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

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

а неплохо так. вы получили зарплату, но это не точно

Поэтому там совсем по другому мыслят. Нужно уметь работать с eventual consistency.

Это не про монгу. В ней только один мастер. Если упадет, то все.

Зря вы монгу тащите. Вот тебе нужно записать транзакцию (списали или добавили) и возможно где-то изменить остаток на счету. Без транзакций на уровне БД ты этого не сделаешь, т.к. записать нужно в две таблицы. В монге атомарность только на документе. Нет гарантии, что два документа будут записаны.

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

надо просто будет всех клиентов запихнуть в один документ. ba-dum-tsss!

Ограничение в 16 мегабайт на документ.

Ограничение в 16 мегабайт на документ.

будет небольшая система. для очень богатых людей.

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

Есть такое понятие как transaction isolation. Не нужны «грязные чтения» используй правильный уровень изоляции. Но это все применимо к обычной СУБД. Как там у монги с этим я не в курса

а неплохо так. вы получили зарплату, но это не точно

Ага ) да я сам хз как это работает. Не имел с этим дел. Интересно, как люди решают эту проблему в NoSQL.

монга для постороения платежной системы

чуть чаем не подавился :)

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

Владислав, а почитайте книжку с кабаном на обложке. прямо вот рекомендую.

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

Транзакция атомарна. Все это решили уже до тебя. Тебе это гарантирует поставщик БД. Ты сам должен это делать, только для тренировки навыков.

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

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

https://docs.mongodb.com/manual/tutorial/perform-two-phase-commits/

Транзакция атомарна. Все это решили уже до тебя. Тебе это гарантирует поставщик БД. Ты сам должен это делать, только для тренировки навыков.

не все субд поддерживают транзакции, но атомарность - почти все

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

заодно сможете отстаивать выбор инструмента, если вдруг спросят.

Если ещё writeConcern подкрутить, то можно и платёжную систему писать https://docs.mongodb.com/manual/reference/write-concern/ Только реляционные СУБД с нормальными транзакциями это позволяют делать куда проще

https://mobile.twitter.com/OpenJDK/status/1009180659024158720

Прощай nashorn

а че вместо него?

грааль что ли ?

https://mobile.twitter.com/OpenJDK/status/1009180659024158720

Кто-то будет скучать?

В монгу к слову тоже транзакции завозят... Но ведь и документы можно в постгрессесе хранить :)

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

спасибо большое, буду читать

Кто-то будет скучать?

Кто-то тут был кому я помогал с этим

Кто-то будет скучать?

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

ERROR: S client not available

В общем то мне кажется накручивать транзакции на монгу это какой-то неправильный путь. Должен быть какой-то true way в NoSQL. Правда черт его знает что это должно быть ) взгляд слишком замылен реляционными СУБД.

Прощайте прозрачные изображения для записи https://mobile.twitter.com/OpenJDK/status/1002601279225499649

Сначала Рино задеприкейтился теперь и нашорн

спасибо большое, буду читать

А чем вам не подошел potsgres? Ничего выдумывать не нужно, ничего не тестировать. Запустили транзакцию, изменили баланс, завершили транзакцию. Все довольны. Никаких блокировок в приложении, все на уровне БД.

Прощайте прозрачные изображения для записи https://mobile.twitter.com/OpenJDK/status/1002601279225499649

>JPEG >прозрачные

>JPEG >прозрачные

Альфаканал только на чтение поддерживаться будет вроде как.

Ладно там отпилили jee часть хрен бы с ней. Конечно на 11й версии наш код перестал запускаться, но это не смертельно (: Но это прямо таки прикольный способ отрезания функционала, когда у тебя какие-то куски api перестают работать. Это прямо таки не победа, это фиаско.

Ладно там отпилили jee часть хрен бы с ней. Конечно на 11й версии наш код перестал запускаться, но это не смертельно (: Но это прямо таки прикольный способ отрезания функционала, когда у тебя какие-то куски api перестают работать. Это прямо таки не победа, это фиаско.

это что у вас там такое, чтто на 10ой работало, на 11ой нет?

это что у вас там такое, чтто на 10ой работало, на 11ой нет?

javax.xml.bind пропал

Вырезание jee обернется для многих сюрпризами в самых неожиданных местах (:

а я еще на 10ой его добавил как мавен депенденси

так как он уже был дипрекейт

и надо было уже на 10тке реагироваить

так что твой случай покаталеьный в обратном, забили хер )

и надо было уже на 10тке реагироваить

У меня каждая новая dependency для проекта это сборка ее из исходников.

а зачем сборка из исходников?

а зачем сборка из исходников?

Требования по информационной безопасности.

Что тут сказать

Требования по информационной безопасности.

Серьезные у вас требования. Обычно ставят своё зеркало репозиториев с проверенными jar архивами.

Серьезные у вас требования. Обычно ставят своё зеркало репозиториев с проверенными jar архивами.

Какие есть (:

Требования по информационной безопасности.

ну весело вам )

Требования серьёзные, но при этом сразу мигрируете на новые версии Java?

Очень. Особенно, когда оракл половину исходников потеряла при закрытии сайтов по Java

Требования серьёзные, но при этом сразу мигрируете на новые версии Java?

Не сразу, но проект нами для миграции готовится.

ну весело вам )

Среди репозиториев был репозиторий с библиотекой конвертации величин (: В итоге в последнем релизе с гитхаба отсутствует пловина функционала (:

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

Ещё "какая-то матерь" в этом процессе участвовала.

Требования серьёзные, но при этом сразу мигрируете на новые версии Java?

Если проект не готов, то нет повода для разговора о миграции

https://mobile.twitter.com/OpenJDK/status/1009180659024158720

А замена какая-нибудь будет?

@avaren514796 тебе сюда @javastart