Антон Кекс: Как нам спасти Java?

Здравствуй, %USERNAME%!

Наткнулся в этих ваших интернетах на одно замечательное видео — презентация Антона Кекса в двух частях.
Приглашаю вас посмотреть это видео и присоединиться к дискуссии в комментариях. После опубликования поста я собираюсь выслать на указанные на слайдах контакты Антона приглашение присоединиться к нам, и ответить на наши вопросы. Надеюсь, у него уже есть аккаунт на Хабре, ибо инвайта у меня нету.







Конечно, большая часть советов весьма и весьма дельная. Про JRebel, про простоту кода, про автоматизацию. Но.
Все хорошо в меру. По моему, Антон моментами слишком перебарщивает в стремлении к простоте. Не для того Java создавалась, с таким подходом прямая дорога в PHP (без холиваров, пожалуйста). Я не по наслышке знаю, что такое Ынтырпрайз, но не выкидывать же теперь J2EE, и кодить сложные, запутанные, распределенные и интегрированные между собой проекты на J2SE? Тут конечно, если опыта хватает, и это только твой проект, и ты знаешь что делаешь — пожалуйста, и правда так проще и красивее выйдет. И быстрее. А если проект большой, как же порог вхождения новеньких? Джава бины, томкаты, JSF и хибернейты как де-факто стандарты знают все (для того оно все и сертифицировано), а твои собственные велосипеды на Pure J2SE — нет, будь они хоть тысячу раз красивые, pure, simple и еще куча прилагательных. И никто не спорит, что они, возможно, будут работать лучше и быстрее. Аналогично и с подходом к архитектуре, к менеджерам, к архитекторам, к эстимейтам. Ну нельзя же писать красивый код ради красивого кода. Мы же все пишем код для бизнеса, который так или иначе нас кормит. А раз это бизнес, а не песочница для программистов-утопистов, нельзя не учитывать потребности, а иногда и желания других участников этого бизнеса — в том числе менеджеров и архитекторов. Они не просто так картинки рисуют. Пока мы тут код пишем, кто то продумывает маркетинг продукта, выход на рынок, прорабатывает потенциальных клиентов\покупателей\заказчиков, и все они не могут делать свою работу, не зная, что же там делают программисты.
Так что повторюсь — все хорошо в меру.

Я не покритиковать тут собрался, доклад мне понравился. Я и сам придерживаюсь принципа KISS. Но мне и правда не понятно, как Антон относится к такой точке зрения, и знает ли о ней. Либо Антон пропагандирует никогда не работать в Ынтырпрайзе, и получать драйв только от заряженных позитивом стартапов?
А еще мне интересно, как хабраобщество смотрит на позицию Антона?
Может, я и сам не правильно мыслю? Вообщем, Антон, попытайтесь «продать мне ваш продукт».

UPD:
Мой пост о Maven, кстати, хорошо объясняет мою позицию. Не надо быть таким, ммм… единоличником. К сожалению, солнце вокруг нас (программистов) не вращается. У нас тут недавно даже попытались высмеять подобное отношение к себе, любимым.
Share post

Comments 60

  • UFO just landed and posted this here
      +3
      Я думаю, исходный позыв правильный. Там речь идет о том, как нам выбраться из ужасной монструозности Ынтырпрайза.
      • UFO just landed and posted this here
          +1
          Я абсолютно согласен. Это характерная черта. Даже само название Java 2 Ынтырпрайз Edition как-бы намекает.
          Речь идет немного о другом. Я работал на проекте, который был рожден в индии, и где джава код при старте читал XML, из них генерировал другие XML, XSD, и другой джава код. Это все потом запускалось как сервисы. Кастомеры — всемирно известные концерны-гиганты. Вот от чего надо уходить. Это уже не Ынтырпрайз, это, извините, д****е**зм.
          • UFO just landed and posted this here
            • UFO just landed and posted this here
                0
                В джаве этот процесс идет уже давно. В ынтырпрайзе — только собирается) Большинство проектов еще на JRE 1.6, а некоторые есть даже на 1.5.
          0
          В докладе имеется ввиду не язык конечно, а проекты на java, которые очень часто излишне переусложнены.
          +3
          «Где просто — там Ангелов со сто, а где мудрено — там ни одного» (Амвросий Оптинский)
            0
            Действительно, если сравнивать Spring и Play для разработки веб приложений, то первый будет уж очень накрученным.
              +1
              А о чём доклад вкратце, какие тезисы?
                0
                Там о том, что иногда имеет смысл потратить 1 час 21 минуту и 21 секунду на просмотр интересного доклада.
                +7
                А зачем спасать Java, когда есть Scala, Clojure, Groovy и масса прочих?
                  +1
                  ИМХО затем, что загнись Java — прокиснет и JVM
                    0
                    Привет всем :-)
                    Ну поинт именно в том, что народ бежит использовать эти языки, намучившись с Java, хотя сам язык Java не так уж и плох, а кошмар — это энтерпрайз проекты, которые пишут на Java в крупных компаниях.
                      0
                      Второй важный поинт — это обязательно попишите на Scala и Groovy, чтобы понять как можно лучше на Java писать. В свое время такое говорили про Java и С++
                    0
                    Бред, все в кучу смешано. Давайте спасать индусов которые лепят все куда где лепится?

                    Там где действительно применим ынтерпрайз эдишн, альтернатив ему пока что нету. А тот кому в голову с бодуна захотелось портлеты и rmi в среднем веб-приложении — извините, сам себе папа карло

                    «Давайте в нашей вселенной среднее веб-приложение будет включать весь JEE стек, теперь спасем нас и будем писать код где меньше скобок и меньше пустых строк»

                    И вообще кстати очень легко и просто из удобной аудитории в 2013 году поливать стек технологий который уже второй десяток разменял, когда опенсоурс наконец подтянулся настолько, чтобы откусить под себя кусок

                      +2
                      Выше было насчет видосов.
                      Насчет вопроса ТС, нужно понимать, что JEE — это не куча непонятных сокращений, это готовый костяк архитектуры солидного и далеко не только веб распределенного приложания, такой себе гигантский ruby-on-rails для продуктов который пишут компании или для компаний уровня IBM или Oracle

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

                      А в случае обычных веб-сервисов и жалкого десятка jsp страниц можно сколько угодно переливать из пустого в порожнее и улучшать качество и красивость своих геттеров и сеттеров
                        +5
                        Имхо Антон пытается донести, что «не нужно юзать быть самому себе злобным Буратино» и усложнять там, где можно обойтись простыми вещами. К тому же данный товарищ имеет имеет вполне себе солидный опыт с J2EE (http://ee.linkedin.com/in/antonkeks). Так что вполне можно прислушаться к его мнению.

                        Ant, War, Ear, Deploy, Redeploy etc.

                        Я когда с Websphere Portal работал и приложениями с портлетами, то мне хотелось блевать, когда после очередного редеплоя эта адова машина зависала и помогало только удаление аппликации, рестарт контейнера и установка заново. Иногда бывали очень неудачные дни(примерно раз в пару месяцев, когда контейнер просто отказывался стартовать) и помогал только снос контейнера и инсталляция его заново. Эта нехитрая операция после оптимизации(предварительная конфигурация контейнера и просто копирование этих гигабайтов данных из одной папки[configured_websphere] в другую[websphere_portal_61]) занимала у меня час.

                        А и да, средний редеплой длился так себе 15 минут. В удачные дни. Проект по добавлению одной гребаной формочки длился по паре недель(в лучшем случае).

                        О какой нахрен продуктивности тут может идти речь?

                        С моей маленькой колокольни человека, измучанного WebSphere Portal'ом могу лишь согласиться с Антоном.
                          +1
                          В этом я тоже абсолютно согласен. Как я и сказал, большая половины выступления мне понравилась. Но когда, например, Антон говорил, что в if не надо писать скобки, и вообще можно обойтись тренарным оператором — меня как-то передергивало.
                          О его солидном опыте я знаю, мой опыт нервно курит в сторонке. Потому очень жажду дискуссии на эту тему. Хотя, с другой стороны больше половины этого опыта — преподавание в вузе и работа на банк. Я, конечно, не знаю как там у них в Таллине, но есть мнение, что такой опыт заставляет мыслить несколько узковато.
                            0
                            С какими-то вещами можно и не соглашаться. Наверное это нормально. Лично я не нахожу ничего плохого в использовании тернарных операций(иногда). Ключевое слово здесь иногда.

                            >> Хотя, с другой стороны больше половины этого опыта — преподавание в вузе и работа на банк.
                            Преподавание в ВУЗе как я понимаю это не более, чем хобби. На хабре есть товарищ из компании Антона: asolntsev. Можно его позвать в данное обсуждение. Через него, наверное, и до самого Антона достучаться было бы проще.
                              +1
                              Да в использовании тренарных операций и нет ничего плохого, по сути. Но сам момент — сначала убираем скобки, вот теперь классно. Хотя нет, давайте вообще тренарный оператор заюзаем.
                              Как по мне, это не упростило читабельность кода, а усложнило ее. Убрало «блоки» кода, между которыми я мог фокусировать свое внимание. Меньше строк кода — не значит читабельнее.
                              Я думаю, Антон читает мыло, так что рано или поздно он тут появится :)
                              0
                              Решение с тернарным оператором мне больше понравилось, чем с кучей if'ов и отсутствием скобок.
                                0
                                Про скобки можно много спорить. Во времена C ещё спорили про "{" на той же строке или на новой :-)
                                Я сторонник читабельного кода и движения Clean Code, и делюсь своим опытом. К тому же, я много писал на Scala, что тоже позволило переосмыслить то, как мог бы выглядеть код. Короче и лаконичнее = лучше.
                                  0
                                  В данном конкретном случае на видео, тренарный оператор забрал у меня возможность переключатся между контекстами блоков кода (где у нас и-или-или, а где сам код конкретного кейса). Дело привычки, наверное. Но для меня код стал сложнее. Короче ведь не всегда лучше, а то снова начнем называть переменные a, b и c.
                              0
                              Я, конечно, все два с половиной часа не слушал :), но и правда «все в кучу смешано».
                              Плюс к тому всё это уже не так актуально — я даже полез проверять, в каком году это видео было выложено. Энтерпрайз, конечно, бывает разный, но, по моему опыту, он уже ушёл далеко вперёд, пропогандирует тот же Agile Software Craftsmanship, предпочитает легковесную архитектуру и давно практически не использует JEE.
                              Хотя в своё время тяжёлого (теперь уже легаси) кода наворотить успели, да.
                                +1
                                К большому сожалению, актуально. И JEE6 — это тоже кошмар, хоть и гораздо лучше, чем предыдущие версии. Даже сейчас, пока вы читаете этот комментарий, кто-то генерит классы в NetBeans или начинает новый проект на Liferay или WebSphere portal. Я призываю этих людей решать проблемы своих клиентов более простыми и дешёвыми путями. Сделать что-то сложно всегда проще, чем сделать просто.
                                  0
                                  ок, будем считать, что у меня продвинутый энтерпрайз :) но правда, я давно уже такого не встречал.
                                  но тогда, конечно, проблема не в том, что энтерпрайз, а в квалификации этих «архитекторов»
                                0
                                интересно рассказывает, многое знакомо.
                                  0
                                  Какой-то сумбур в голове у меня от этого доклада. По-моему нужно делать проекты на подходящих для этого средствах. Нужен небольшой web-проект — напиши его на Groovy + Grails или Scala + Lift (это если java-стэк), PHP или Ruby on Rails(если хочешь на чем-то другом покодить). Но вот документооборот газпрома на Visual Basic писать наверное не стоит(хотя можно попробовать :) ).
                                    +1
                                    OMG, опять видео длительностью целый час. :( Да целых два. Текст или презентация есть?
                                    0
                                    как же он прав, до сих пор рад тому дню, когда начал разработку на Objective-C. После JAVA это как будто с механической коробки передач на автомат пересел, вроде бы результат тот же, а путь достижения цели гораздо проще и понятнее
                                      0
                                      Ух ты. Может статью напишете как вы на Objective-C пишете аналоги JEE приложениям? Да еще и быстрее и удобнее чем на java.
                                        0
                                        я не про аналоги, я про простоту
                                          0
                                          Вы на Objective-C веб-приложения пишите? Если нет, то Ваш комментарий насчет сравнения Objective-C с Java в данном контексте(на мой взгляд) тянет в лучшем случае на сравнение мягкого с теплым.
                                            0
                                            а Вы на Objective-C хоть что-то серьезное писали, чтобы сравнивать?
                                              0
                                              У Java и Objective-C довольно-таки разные сферы применения, поэтому в общем и целом их сравнивать некорректно. На счёт простоты согласен, Objective-C не имеет того сумасшедшего багажа фраемворков, библиотек и т.п., которыми насыщен «мир» Java. Да там и не требуется такое количество разнообразных штуковин.

                                              Да вы и сами это знаете, работали ведь на обеих платформах. Не мне вам говорить.
                                                0
                                                +100500, согласен полностью.
                                                К сожалению, коллеги по цеху увели меня в сторону сравнения, а ведь основная мысль была не в этом, конечно же прямо сравнивать не стоит — разные инструменты, но степень простоты и удобства работы с ObjC по сравнению с Java не может не радовать.

                                                Кстати, возвращаясь к сравнению, имею 5летний опыт j2me/BB разработки, вот их уже можно сравнить с ObjC. Сравнение не в пользу первой, но не об этом речь.
                                                  0
                                                  Из википедии:

                                                  Java Platform, Micro Edition (Java ME, ранее — Java 2 Micro Edition, J2ME) — подмножество платформы Java для устройств, ограниченных в ресурсах,


                                                  Тобишь подмножество J2SE вы выдаете за язык Java, как таковой и сравниваете с тем, что вам комфортнее программировать на Objective-C под iPhone/i<что-то там>.
                                                0
                                                Я никогда не писал ничего на Objective-C и сравнивать не пытаюсь. Но мне было бы интересно узнать какого типа серьезные приложения вы пишите/писали на Objective-C и соответственно на Java. Так как выше вы упоминаете опыт работы с обоими этими языками.
                                              +5
                                              А… ну тогда да… Если пофиг на аналогию… то конечно.
                                              Я когда перешел с C# на Java, со сменой работы, новый офис в 5 мин от дома оказался.
                                              И так все просто стало. Никаких пробок, никаких метро…
                                              Вроде бы результат тот же, а путь достижения цели гораздо проще и понятнее.
                                              Так что назад с Java на C# я ни ногой, да.
                                        +1
                                        Ынтерпрайс, шмынтырпрайз… Только хардкор, только громадные проекты на SE в одиночку :D
                                          0
                                          Антон молодец, как технарь он прав на все 100%. Но тема в том что если ты не продаешь Oracle, Liferay, Websphere, то откатов тебе не видать. Маркетинг, такой маркетинг…
                                            +1
                                            вы путаете термины — «маркетинг» и «продажи»
                                              0
                                              Нам как бы маркетинг говорит что только Oracle, Liferay, Websphere… решит все проблемы. По факту многие вещи можно решить более дешевыми средствами, и чаще всего быстрее. Так как маркетинг давит на крупные конторы сильно, то собственно и продажи идут достаточно хорошо. А где продажи там и откаты. :)
                                            +2
                                            Смотрел я это видео раньше. Антон призывает использовать средства адекватные задаче. В большинстве случаев действительно хватает простых средств, предоставляемых Java, фреймворком и парой open-source библиотек. Но, «мужики-то не знают», и по инерции выбирают сложную архитектуру для решения любой задачи. На работе меня неоднократно спрашивали: «а какой сервер приложений вы используете в проекте»? Людям было непросто объяснить, что приложение было standalone и пускалось из командной строки (Apache Camel+ActiveMQ).

                                            Я много работал с J2EE, и могу с уверенностью сказать, что это сложная, медленная, неудобоваримая и в 95% случаев абсолютно бесполезная куча соглашений с перманентно глючной имплементацией. При том, что в J2EE продумана и описана архитектура, в ней совершенно за кадром остается методология разработки. Цикл по типу Insert trace-compile-package-deploy-test-see logs-undeploy мне напоминает прошлый век. Arquillian и JRebel — это извращения, призванные на борьбу с ветряными мельницами. Поэтому, я выдвину тезис: любую задачу, которую вы решаете с помощью J2EE я решу без нее в 10 раз быстрее, дешевле, проще и надежнее. Практически ВСЕ технологии J2EE, которые Вы используете либо не нужны для решения задачи, либо имеют более простую альтернативу.
                                              0
                                              Весьма громкое заявление. Не боитесь, что наплыв HRов не будет давать вам спать после такого?
                                              А если серьезно, то с первым абзацем абсолютно согласен. Но во втором вы сами себе противоречите. Спорю, что какой-нибудь большой контракт-монитор-чегототам-крутой-менеджер, который будет расчитан на огромные мировые корпорации и концерны, вы не напишите на Java без J2EE?
                                              0
                                              Я понял претензии к Очень Серьезным Фирмам тм, но не совсем понимаю что происходит с маленькими веб аппликациями. Например я работал в небольшой SEO конторе. Это был мой первый веб проект, поэтому для юай я взял Vaadin (не время было учить и писать сиэсэсы). Чтобы экономить время на написании стандартных запросов, туда же присобачил Hibernate. Чтобы мои валидации легко писались и были не связаны с представлением, я использовал JSR валидации аннотациями. Разбираться самому с лайфсайклом некоторых обьектов, да и чтобы не таскать все через конструкторы/статик методы я использовал Spring, который создавал мои сервисы, имеющие бизнес логику и инжектил их в юай листенеры (например нажатия на кнопку). Ну и конечно не стал придумывать свой велосипед с квадратными колесами, и заюзал Spring Security для авторизации/аутентикации. Конечно Maven для всего этого счастья, не буду же я таскать джары с собой. В результате выходит немало фрэймворков, но работа шла очень быстро, и томкат стартовал за 10 секунд.
                                              Внимание вопрос, как я мог сэкономить время НЕ ИСПОЛЬЗУЯ все эти библиотеки и фрэймворки?
                                                +1
                                                все вышеописанное еще не подпадает под J2EE :0)
                                                Вот EJB, WebSphere(Portal), портлеты etc — вот это уже J2EE.
                                                P.S. Если твое веб-приложение стартует быстрее, чем за минуту, то это не тру ынтырпрайз :)
                                                  0
                                                  Почему это не попадает? Hibernate вполне себе JPA, заменим @Autowired на
                                                  @Inject
                                                  (хабрапарсер) и будет тоже J2EE стандарт. Я посмотрел только первую часть, но так и не увидел четкого распределения между «легким» J2EE (Spring и компания).
                                                  А с идеей «уменьшения джаров» это может дойти до переписывания log4j, apache commons и google collections. Мы же этого не хотим, правда?
                                                  Но в общем конечно да, абсолютно согласен с тем, что весь этот большой Ынтерпрайз должен сдохнуть и быть заменен минимум легковесных решений. И то что JSF, EJB это гнилые помидоры, которым место не в нашем (прекрасном) мире.
                                                    0
                                                    Насчет хибернейта — первее появился EJB, от которого все стонали. Затем появился Hibernate несколько позже с попыткой сделать мир лучше. Народу хибернейт начал нравиться. В 2006-ом вышел JPA и Hibernate его тоже поддерживает так же как и JPA2. Тобишь появились стандарты, которые слизаны с вменяемой имплементации.

                                                    Я сам использую Spring и Hibernate очень активно и не нашел пока что альтернатив(именно в плане скорости разработки/поддержки кода).
                                                    Да, есть тот же Google Guice для Dependency Injection, но у меня с ним не срослось. Есть наверное и еще какие-то другие вещи, но я опыта с ними не имею.
                                                    Spring MVC можно противопоставить Struts 2 (оставил довольно теплые чувства). Но и первый тоже очень ничего и новый проект я начал на нем.

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

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

                                                    Насчет JAR'ов я с Антоном частично согласен.

                                                    Но это не значит, что я откажусь от google guava, apache commons etc.
                                                    Имхо это проблема фреймворкописателей — уменьшить количество зависимостей тянущихся. Чем меньше зависимостей тянет либа, тем лучше. В плане сакмого конечного приложения это наверное не совсем так. Я не буду писать второй log4j/slf4j :) Но и подключать что-то что я не использую я тоже не буду :)
                                                      0
                                                      Ваше джававозрение полностью соответствует моему, просто этот слой «легкого J2EE» был оставлен за кадром, и я не совсем понял, критиковался он тоже или нет.
                                                0
                                                Класс! Чувствую смену парадигмы ООП в Java: язык и способы его использования становятся ближе к языкам описания предметной области. Главное, что это поняли сами разработчики приложений.
                                                  0
                                                  antonkeks мне кажется, что сейчас есть один разумный довод использовать EE и EE серверы — JTA. Я смотрел и твои доклады, и доклад Алименкова про No JMS, мне всё нравится… Но не всегда получается. И вот как только мне нужны транзакции на JMS+какую-нить БД — без JTA становится грустно. Эмулировать XA на редисе я так и не научился :(.
                                                    0
                                                    Вопрос в том, реально ли нужен JTA и стоит ли ради нее возиться с дерьмом JEE? Все остальное доступно по отдельности, лучше, удобоваримее, и легко подцепляется в виде библиотек.
                                                    — Во-первых, JTA создает ложную уверенность в atomicity. Если у Вас грохается ресурс на критической операции (сеть, машина, диски), транзакция становится unrecoverable. Внезапно, transaction manager перестает создавать другие транзакции, пока не будет решена проблема с грохнувшейся. Как это делается в конкретно взятом сервере — знают несколько человек в мире. Пока админ судорожно разбирается как откатить грохнувшуюся транзакцию, где подправить какие данные, работа стоИт.
                                                    — Во-вторых, впринципе невозможно создать надежную координированную работу нескольких удаленных систем (теорема CAP). Можно лишь немного приблизить работу, исходя из неочевидных предположений, например, когда сеть и железо более-менее надежно, вероятность сбоя при координированном коммите ничтожно мала. JTA неявно скрывает это, вселяя ложную уверенность в надежности.
                                                    — В-третьих, JMS без транзакции имеет ручной ACK, который является аналогом коммита. При этом брокер считает месседж обработанным и удаляет из очереди. Поэтому сначала делаем процессинг месседжа, коммит транзакции в DB, а потом ручками посылаем ACK брокеру. При такой структуре программист уже обязан въявную подумать, что случится, если на ACK грохнется ресурс. JMS в этом случае попробует еще раз прислать сообщение. Обычное решение — вести контроль дубликатов: сохранять в базе данных ID уже обработаных месседжей.

                                                    Как вариант, можно минимизировать риски от сбоя сети, если поднимать локально на каждый instance приложения embedded брокер, а затем связывать их в кластер. Сообщения надежно (если нет сбоя железа) отдаются и принимаются только от локального брокера, который уже в свою очередь занимается их пересылкой по сети.

                                                    Если так нужен JTA, то есть JBoss Transactions, или Atomikos. Оба интегрируются в Spring. Но в любом случае, JTA — это не панацея, а скорей вред.
                                                      0
                                                      Как минимум с JTA мы уверены в БД. Все вменяемые БД поддерживают двухфазный коммит. Так что в БД мы более-менее уверены, это обычно самое главное. Насчёт сообщений — они могут дублироваться и теряться. Как правило лучше пусть дублируются. В любом случае констрейнты в БД не дадут нам сотворить дикого ада. При этом если мы прочли сообщение из очереди, записали что-то в БД и упали — в БД ничего не запишется, сообщение уйдёт на ределивери. И это классные гарантии, которые нужны в распределённых больших системах. Я не специалист, но мне говорили, что у атомикоса есть какие-то ограничения по перерегистрации ресурсов.
                                                        0
                                                        Все, что Вы описали, делается быстрее и надежней без JTA. Любая БД всегда поддерживает обычные (локальные) транзакции. Случай, когда нужно обращаться (а именно апдейтить) сразу несколько БД довольно редок, и как правило говорит о плохой архитектуре. В этом случае лучше разделить апдейты разных БД в разные транзакции, а иногда даже делать это асинхронно при помощи того же JMS.

                                                        JTA именно дает гарантии, что сообщение не будет продублировано или потеряно, а обработано атомарно вместе с апдейтом БД. В случае, если двухфазный коммит фейлится на второй фазе (да, такое бывает!), то отваливается весь TransactionManager, и будет терпеливо ждать, пока его не починят ручками, и не подправят данные. А это реальный геморрой, особенно в случае нескольких БД.

                                                        Без JTA с ручным JMS acknowledgement (ACK) худшее, что может случиться — это когда выполнился коммит в БД, но система свалилась на посылке ACK брокеру. В этом случае случится ределивери (при настроеной персистенции), и возможны дубликаты, которые могут быть проконтролированы отдельно той же БД.

                                                        Так что польза от JTA достаточно сомнительная: они тяжелые, медленные, сложнонастраиваемые (в Weblogic 100+ настроек), сложнотестируемые и как правило глючные. В подавляющем большинстве случаев их использование неоправдано поставленной задачей.
                                                          0
                                                          Ну мы на wildfly живём, у него достаточно просто всё. И да, в моём мире большой многокомпонентной системы, которая разворачивается уже, вроде бы, на 50 серверах, коммит в несколько БД и работу с JMS в одной транзакции как минимум в двух местах приходится использовать. Мы думали над тем, чтобы не делать всё в одной транзакции, но поняли что не можем себе этого позволить. Есть части, где консистентность данных критична.

                                                  Only users with full accounts can post comments. Log in, please.