Хабр Курсы для всех
РЕКЛАМА
Большая витрина: от крупнейших школ до частных авторов. Сравнивайте по цене, длительности, формату и выбирайте самый подходящий курс!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 60
Я думаю, исходный позыв правильный. Там речь идет о том, как нам выбраться из ужасной монструозности Ынтырпрайза.
Я абсолютно согласен. Это характерная черта. Даже само название Java 2 Ынтырпрайз Edition как-бы намекает.
Речь идет немного о другом. Я работал на проекте, который был рожден в индии, и где джава код при старте читал XML, из них генерировал другие XML, XSD, и другой джава код. Это все потом запускалось как сервисы. Кастомеры — всемирно известные концерны-гиганты. Вот от чего надо уходить. Это уже не Ынтырпрайз, это, извините, д****е**зм.
Речь идет немного о другом. Я работал на проекте, который был рожден в индии, и где джава код при старте читал XML, из них генерировал другие XML, XSD, и другой джава код. Это все потом запускалось как сервисы. Кастомеры — всемирно известные концерны-гиганты. Вот от чего надо уходить. Это уже не Ынтырпрайз, это, извините, д****е**зм.
В докладе имеется ввиду не язык конечно, а проекты на java, которые очень часто излишне переусложнены.
«Где просто — там Ангелов со сто, а где мудрено — там ни одного» (Амвросий Оптинский)
Действительно, если сравнивать Spring и Play для разработки веб приложений, то первый будет уж очень накрученным.
А зачем спасать Java, когда есть Scala, Clojure, Groovy и масса прочих?
Бред, все в кучу смешано. Давайте спасать индусов которые лепят все куда где лепится?
Там где действительно применим ынтерпрайз эдишн, альтернатив ему пока что нету. А тот кому в голову с бодуна захотелось портлеты и rmi в среднем веб-приложении — извините, сам себе папа карло
«Давайте в нашей вселенной среднее веб-приложение будет включать весь JEE стек, теперь спасем нас и будем писать код где меньше скобок и меньше пустых строк»
И вообще кстати очень легко и просто из удобной аудитории в 2013 году поливать стек технологий который уже второй десяток разменял, когда опенсоурс наконец подтянулся настолько, чтобы откусить под себя кусок
Там где действительно применим ынтерпрайз эдишн, альтернатив ему пока что нету. А тот кому в голову с бодуна захотелось портлеты и rmi в среднем веб-приложении — извините, сам себе папа карло
«Давайте в нашей вселенной среднее веб-приложение будет включать весь JEE стек, теперь спасем нас и будем писать код где меньше скобок и меньше пустых строк»
И вообще кстати очень легко и просто из удобной аудитории в 2013 году поливать стек технологий который уже второй десяток разменял, когда опенсоурс наконец подтянулся настолько, чтобы откусить под себя кусок
Выше было насчет видосов.
Насчет вопроса ТС, нужно понимать, что JEE — это не куча непонятных сокращений, это готовый костяк архитектуры солидного и далеко не только веб распределенного приложания, такой себе гигантский ruby-on-rails для продуктов который пишут компании или для компаний уровня IBM или Oracle
Так что вы правильно подметили, если это солидный бизнес, а не песочница для утопистов, и нужно делать большое распределенное приложение, то JEE сразу решит кучу головняка за вас и даст масштабируемые рельсы для компноентов такого софта
А в случае обычных веб-сервисов и жалкого десятка jsp страниц можно сколько угодно переливать из пустого в порожнее и улучшать качество и красивость своих геттеров и сеттеров
Насчет вопроса ТС, нужно понимать, что JEE — это не куча непонятных сокращений, это готовый костяк архитектуры солидного и далеко не только веб распределенного приложания, такой себе гигантский ruby-on-rails для продуктов который пишут компании или для компаний уровня IBM или Oracle
Так что вы правильно подметили, если это солидный бизнес, а не песочница для утопистов, и нужно делать большое распределенное приложение, то JEE сразу решит кучу головняка за вас и даст масштабируемые рельсы для компноентов такого софта
А в случае обычных веб-сервисов и жалкого десятка jsp страниц можно сколько угодно переливать из пустого в порожнее и улучшать качество и красивость своих геттеров и сеттеров
Имхо Антон пытается донести, что «не нужно юзать быть самому себе злобным Буратино» и усложнять там, где можно обойтись простыми вещами. К тому же данный товарищ имеет имеет вполне себе солидный опыт с J2EE (http://ee.linkedin.com/in/antonkeks). Так что вполне можно прислушаться к его мнению.
Ant, War, Ear, Deploy, Redeploy etc.
Я когда с Websphere Portal работал и приложениями с портлетами, то мне хотелось блевать, когда после очередного редеплоя эта адова машина зависала и помогало только удаление аппликации, рестарт контейнера и установка заново. Иногда бывали очень неудачные дни(примерно раз в пару месяцев, когда контейнер просто отказывался стартовать) и помогал только снос контейнера и инсталляция его заново. Эта нехитрая операция после оптимизации(предварительная конфигурация контейнера и просто копирование этих гигабайтов данных из одной папки[configured_websphere] в другую[websphere_portal_61]) занимала у меня час.
А и да, средний редеплой длился так себе 15 минут. В удачные дни. Проект по добавлению одной гребаной формочки длился по паре недель(в лучшем случае).
О какой нахрен продуктивности тут может идти речь?
С моей маленькой колокольни человека, измучанного WebSphere Portal'ом могу лишь согласиться с Антоном.
Ant, War, Ear, Deploy, Redeploy etc.
Я когда с Websphere Portal работал и приложениями с портлетами, то мне хотелось блевать, когда после очередного редеплоя эта адова машина зависала и помогало только удаление аппликации, рестарт контейнера и установка заново. Иногда бывали очень неудачные дни(примерно раз в пару месяцев, когда контейнер просто отказывался стартовать) и помогал только снос контейнера и инсталляция его заново. Эта нехитрая операция после оптимизации(предварительная конфигурация контейнера и просто копирование этих гигабайтов данных из одной папки[configured_websphere] в другую[websphere_portal_61]) занимала у меня час.
А и да, средний редеплой длился так себе 15 минут. В удачные дни. Проект по добавлению одной гребаной формочки длился по паре недель(в лучшем случае).
О какой нахрен продуктивности тут может идти речь?
С моей маленькой колокольни человека, измучанного WebSphere Portal'ом могу лишь согласиться с Антоном.
В этом я тоже абсолютно согласен. Как я и сказал, большая половины выступления мне понравилась. Но когда, например, Антон говорил, что в if не надо писать скобки, и вообще можно обойтись тренарным оператором — меня как-то передергивало.
О его солидном опыте я знаю, мой опыт нервно курит в сторонке. Потому очень жажду дискуссии на эту тему. Хотя, с другой стороны больше половины этого опыта — преподавание в вузе и работа на банк. Я, конечно, не знаю как там у них в Таллине, но есть мнение, что такой опыт заставляет мыслить несколько узковато.
О его солидном опыте я знаю, мой опыт нервно курит в сторонке. Потому очень жажду дискуссии на эту тему. Хотя, с другой стороны больше половины этого опыта — преподавание в вузе и работа на банк. Я, конечно, не знаю как там у них в Таллине, но есть мнение, что такой опыт заставляет мыслить несколько узковато.
С какими-то вещами можно и не соглашаться. Наверное это нормально. Лично я не нахожу ничего плохого в использовании тернарных операций(иногда). Ключевое слово здесь иногда.
>> Хотя, с другой стороны больше половины этого опыта — преподавание в вузе и работа на банк.
Преподавание в ВУЗе как я понимаю это не более, чем хобби. На хабре есть товарищ из компании Антона: asolntsev. Можно его позвать в данное обсуждение. Через него, наверное, и до самого Антона достучаться было бы проще.
>> Хотя, с другой стороны больше половины этого опыта — преподавание в вузе и работа на банк.
Преподавание в ВУЗе как я понимаю это не более, чем хобби. На хабре есть товарищ из компании Антона: asolntsev. Можно его позвать в данное обсуждение. Через него, наверное, и до самого Антона достучаться было бы проще.
Да в использовании тренарных операций и нет ничего плохого, по сути. Но сам момент — сначала убираем скобки, вот теперь классно. Хотя нет, давайте вообще тренарный оператор заюзаем.
Как по мне, это не упростило читабельность кода, а усложнило ее. Убрало «блоки» кода, между которыми я мог фокусировать свое внимание. Меньше строк кода — не значит читабельнее.
Я думаю, Антон читает мыло, так что рано или поздно он тут появится :)
Как по мне, это не упростило читабельность кода, а усложнило ее. Убрало «блоки» кода, между которыми я мог фокусировать свое внимание. Меньше строк кода — не значит читабельнее.
Я думаю, Антон читает мыло, так что рано или поздно он тут появится :)
Решение с тернарным оператором мне больше понравилось, чем с кучей if'ов и отсутствием скобок.
Про скобки можно много спорить. Во времена C ещё спорили про "{" на той же строке или на новой :-)
Я сторонник читабельного кода и движения Clean Code, и делюсь своим опытом. К тому же, я много писал на Scala, что тоже позволило переосмыслить то, как мог бы выглядеть код. Короче и лаконичнее = лучше.
Я сторонник читабельного кода и движения Clean Code, и делюсь своим опытом. К тому же, я много писал на Scala, что тоже позволило переосмыслить то, как мог бы выглядеть код. Короче и лаконичнее = лучше.
В данном конкретном случае на видео, тренарный оператор забрал у меня возможность переключатся между контекстами блоков кода (где у нас и-или-или, а где сам код конкретного кейса). Дело привычки, наверное. Но для меня код стал сложнее. Короче ведь не всегда лучше, а то снова начнем называть переменные a, b и c.
Я, конечно, все два с половиной часа не слушал :), но и правда «все в кучу смешано».
Плюс к тому всё это уже не так актуально — я даже полез проверять, в каком году это видео было выложено. Энтерпрайз, конечно, бывает разный, но, по моему опыту, он уже ушёл далеко вперёд, пропогандирует тот же Agile Software Craftsmanship, предпочитает легковесную архитектуру и давно практически не использует JEE.
Хотя в своё время тяжёлого (теперь уже легаси) кода наворотить успели, да.
Плюс к тому всё это уже не так актуально — я даже полез проверять, в каком году это видео было выложено. Энтерпрайз, конечно, бывает разный, но, по моему опыту, он уже ушёл далеко вперёд, пропогандирует тот же Agile Software Craftsmanship, предпочитает легковесную архитектуру и давно практически не использует JEE.
Хотя в своё время тяжёлого (теперь уже легаси) кода наворотить успели, да.
К большому сожалению, актуально. И JEE6 — это тоже кошмар, хоть и гораздо лучше, чем предыдущие версии. Даже сейчас, пока вы читаете этот комментарий, кто-то генерит классы в NetBeans или начинает новый проект на Liferay или WebSphere portal. Я призываю этих людей решать проблемы своих клиентов более простыми и дешёвыми путями. Сделать что-то сложно всегда проще, чем сделать просто.
интересно рассказывает, многое знакомо.
Какой-то сумбур в голове у меня от этого доклада. По-моему нужно делать проекты на подходящих для этого средствах. Нужен небольшой web-проект — напиши его на Groovy + Grails или Scala + Lift (это если java-стэк), PHP или Ruby on Rails(если хочешь на чем-то другом покодить). Но вот документооборот газпрома на Visual Basic писать наверное не стоит(хотя можно попробовать :) ).
OMG, опять видео длительностью целый час. :( Да целых два. Текст или презентация есть?
Если просто полистать презентацию, то впечатление останется совсем не то, как после просмотра видео.
P.S. www.slideshare.net/antonkeks/simplicity-8971441
P.S. www.slideshare.net/antonkeks/simplicity-8971441
как же он прав, до сих пор рад тому дню, когда начал разработку на Objective-C. После JAVA это как будто с механической коробки передач на автомат пересел, вроде бы результат тот же, а путь достижения цели гораздо проще и понятнее
Ух ты. Может статью напишете как вы на Objective-C пишете аналоги JEE приложениям? Да еще и быстрее и удобнее чем на java.
я не про аналоги, я про простоту
Вы на Objective-C веб-приложения пишите? Если нет, то Ваш комментарий насчет сравнения Objective-C с Java в данном контексте(на мой взгляд) тянет в лучшем случае на сравнение мягкого с теплым.
а Вы на Objective-C хоть что-то серьезное писали, чтобы сравнивать?
У Java и Objective-C довольно-таки разные сферы применения, поэтому в общем и целом их сравнивать некорректно. На счёт простоты согласен, Objective-C не имеет того сумасшедшего багажа фраемворков, библиотек и т.п., которыми насыщен «мир» Java. Да там и не требуется такое количество разнообразных штуковин.
Да вы и сами это знаете, работали ведь на обеих платформах. Не мне вам говорить.
Да вы и сами это знаете, работали ведь на обеих платформах. Не мне вам говорить.
+100500, согласен полностью.
К сожалению, коллеги по цеху увели меня в сторону сравнения, а ведь основная мысль была не в этом, конечно же прямо сравнивать не стоит — разные инструменты, но степень простоты и удобства работы с ObjC по сравнению с Java не может не радовать.
Кстати, возвращаясь к сравнению, имею 5летний опыт j2me/BB разработки, вот их уже можно сравнить с ObjC. Сравнение не в пользу первой, но не об этом речь.
К сожалению, коллеги по цеху увели меня в сторону сравнения, а ведь основная мысль была не в этом, конечно же прямо сравнивать не стоит — разные инструменты, но степень простоты и удобства работы с ObjC по сравнению с Java не может не радовать.
Кстати, возвращаясь к сравнению, имею 5летний опыт j2me/BB разработки, вот их уже можно сравнить с ObjC. Сравнение не в пользу первой, но не об этом речь.
Из википедии:
Тобишь подмножество J2SE вы выдаете за язык Java, как таковой и сравниваете с тем, что вам комфортнее программировать на Objective-C под iPhone/i<что-то там>.
Java Platform, Micro Edition (Java ME, ранее — Java 2 Micro Edition, J2ME) — подмножество платформы Java для устройств, ограниченных в ресурсах,
Тобишь подмножество J2SE вы выдаете за язык Java, как таковой и сравниваете с тем, что вам комфортнее программировать на Objective-C под iPhone/i<что-то там>.
Я никогда не писал ничего на Objective-C и сравнивать не пытаюсь. Но мне было бы интересно узнать какого типа серьезные приложения вы пишите/писали на Objective-C и соответственно на Java. Так как выше вы упоминаете опыт работы с обоими этими языками.
А… ну тогда да… Если пофиг на аналогию… то конечно.
Я когда перешел с C# на Java, со сменой работы, новый офис в 5 мин от дома оказался.
И так все просто стало. Никаких пробок, никаких метро…
Вроде бы результат тот же, а путь достижения цели гораздо проще и понятнее.
Так что назад с Java на C# я ни ногой, да.
Я когда перешел с C# на Java, со сменой работы, новый офис в 5 мин от дома оказался.
И так все просто стало. Никаких пробок, никаких метро…
Вроде бы результат тот же, а путь достижения цели гораздо проще и понятнее.
Так что назад с Java на C# я ни ногой, да.
А D не смотрели? Вот 10 причин полюбить язык программирования D dlang.ru/10-prichin-pochemu-ya-lyublyu-yazyk-programmirovaniya-d
Ынтерпрайс, шмынтырпрайз… Только хардкор, только громадные проекты на SE в одиночку :D
Антон молодец, как технарь он прав на все 100%. Но тема в том что если ты не продаешь Oracle, Liferay, Websphere, то откатов тебе не видать. Маркетинг, такой маркетинг…
вы путаете термины — «маркетинг» и «продажи»
Нам как бы маркетинг говорит что только Oracle, Liferay, Websphere… решит все проблемы. По факту многие вещи можно решить более дешевыми средствами, и чаще всего быстрее. Так как маркетинг давит на крупные конторы сильно, то собственно и продажи идут достаточно хорошо. А где продажи там и откаты. :)
Смотрел я это видео раньше. Антон призывает использовать средства адекватные задаче. В большинстве случаев действительно хватает простых средств, предоставляемых Java, фреймворком и парой open-source библиотек. Но, «мужики-то не знают», и по инерции выбирают сложную архитектуру для решения любой задачи. На работе меня неоднократно спрашивали: «а какой сервер приложений вы используете в проекте»? Людям было непросто объяснить, что приложение было standalone и пускалось из командной строки (Apache Camel+ActiveMQ).
Я много работал с J2EE, и могу с уверенностью сказать, что это сложная, медленная, неудобоваримая и в 95% случаев абсолютно бесполезная куча соглашений с перманентно глючной имплементацией. При том, что в J2EE продумана и описана архитектура, в ней совершенно за кадром остается методология разработки. Цикл по типу Insert trace-compile-package-deploy-test-see logs-undeploy мне напоминает прошлый век. Arquillian и JRebel — это извращения, призванные на борьбу с ветряными мельницами. Поэтому, я выдвину тезис: любую задачу, которую вы решаете с помощью J2EE я решу без нее в 10 раз быстрее, дешевле, проще и надежнее. Практически ВСЕ технологии J2EE, которые Вы используете либо не нужны для решения задачи, либо имеют более простую альтернативу.
Я много работал с J2EE, и могу с уверенностью сказать, что это сложная, медленная, неудобоваримая и в 95% случаев абсолютно бесполезная куча соглашений с перманентно глючной имплементацией. При том, что в J2EE продумана и описана архитектура, в ней совершенно за кадром остается методология разработки. Цикл по типу Insert trace-compile-package-deploy-test-see logs-undeploy мне напоминает прошлый век. Arquillian и JRebel — это извращения, призванные на борьбу с ветряными мельницами. Поэтому, я выдвину тезис: любую задачу, которую вы решаете с помощью J2EE я решу без нее в 10 раз быстрее, дешевле, проще и надежнее. Практически ВСЕ технологии J2EE, которые Вы используете либо не нужны для решения задачи, либо имеют более простую альтернативу.
Весьма громкое заявление. Не боитесь, что наплыв HRов не будет давать вам спать после такого?
А если серьезно, то с первым абзацем абсолютно согласен. Но во втором вы сами себе противоречите. Спорю, что какой-нибудь большой контракт-монитор-чегототам-крутой-менеджер, который будет расчитан на огромные мировые корпорации и концерны, вы не напишите на Java без J2EE?
А если серьезно, то с первым абзацем абсолютно согласен. Но во втором вы сами себе противоречите. Спорю, что какой-нибудь большой контракт-монитор-чегототам-крутой-менеджер, который будет расчитан на огромные мировые корпорации и концерны, вы не напишите на Java без J2EE?
Я понял претензии к Очень Серьезным Фирмам тм, но не совсем понимаю что происходит с маленькими веб аппликациями. Например я работал в небольшой SEO конторе. Это был мой первый веб проект, поэтому для юай я взял Vaadin (не время было учить и писать сиэсэсы). Чтобы экономить время на написании стандартных запросов, туда же присобачил Hibernate. Чтобы мои валидации легко писались и были не связаны с представлением, я использовал JSR валидации аннотациями. Разбираться самому с лайфсайклом некоторых обьектов, да и чтобы не таскать все через конструкторы/статик методы я использовал Spring, который создавал мои сервисы, имеющие бизнес логику и инжектил их в юай листенеры (например нажатия на кнопку). Ну и конечно не стал придумывать свой велосипед с квадратными колесами, и заюзал Spring Security для авторизации/аутентикации. Конечно Maven для всего этого счастья, не буду же я таскать джары с собой. В результате выходит немало фрэймворков, но работа шла очень быстро, и томкат стартовал за 10 секунд.
Внимание вопрос, как я мог сэкономить время НЕ ИСПОЛЬЗУЯ все эти библиотеки и фрэймворки?
Внимание вопрос, как я мог сэкономить время НЕ ИСПОЛЬЗУЯ все эти библиотеки и фрэймворки?
все вышеописанное еще не подпадает под J2EE :0)
Вот EJB, WebSphere(Portal), портлеты etc — вот это уже J2EE.
P.S. Если твое веб-приложение стартует быстрее, чем за минуту, то это не тру ынтырпрайз :)
Вот EJB, WebSphere(Portal), портлеты etc — вот это уже J2EE.
P.S. Если твое веб-приложение стартует быстрее, чем за минуту, то это не тру ынтырпрайз :)
Почему это не попадает? Hibernate вполне себе JPA, заменим @Autowired на
А с идеей «уменьшения джаров» это может дойти до переписывания log4j, apache commons и google collections. Мы же этого не хотим, правда?
Но в общем конечно да, абсолютно согласен с тем, что весь этот большой Ынтерпрайз должен сдохнуть и быть заменен минимум легковесных решений. И то что JSF, EJB это гнилые помидоры, которым место не в нашем (прекрасном) мире.
@InjectА с идеей «уменьшения джаров» это может дойти до переписывания log4j, apache commons и google collections. Мы же этого не хотим, правда?
Но в общем конечно да, абсолютно согласен с тем, что весь этот большой Ынтерпрайз должен сдохнуть и быть заменен минимум легковесных решений. И то что JSF, EJB это гнилые помидоры, которым место не в нашем (прекрасном) мире.
Насчет хибернейта — первее появился 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 :) Но и подключать что-то что я не использую я тоже не буду :)
Я сам использую Spring и Hibernate очень активно и не нашел пока что альтернатив(именно в плане скорости разработки/поддержки кода).
Да, есть тот же Google Guice для Dependency Injection, но у меня с ним не срослось. Есть наверное и еще какие-то другие вещи, но я опыта с ними не имею.
Spring MVC можно противопоставить Struts 2 (оставил довольно теплые чувства). Но и первый тоже очень ничего и новый проект я начал на нем.
Мне кажется изначальная проблема как раз состоит в том, что затачивались на какие-то конкретные контейнеры и их «фичи» и без них код не запустить было по большому счету.
У меня нынешний сервис висит на томкате. Когда что-то дополнительное нужно, то прикручиваю. Вообще подумываю о переходе на Jetty (ибо локальный девелопмент веду именно на нем).
Насчет JAR'ов я с Антоном частично согласен.
Но это не значит, что я откажусь от google guava, apache commons etc.
Имхо это проблема фреймворкописателей — уменьшить количество зависимостей тянущихся. Чем меньше зависимостей тянет либа, тем лучше. В плане сакмого конечного приложения это наверное не совсем так. Я не буду писать второй log4j/slf4j :) Но и подключать что-то что я не использую я тоже не буду :)
Класс! Чувствую смену парадигмы ООП в Java: язык и способы его использования становятся ближе к языкам описания предметной области. Главное, что это поняли сами разработчики приложений.
antonkeks мне кажется, что сейчас есть один разумный довод использовать EE и EE серверы — JTA. Я смотрел и твои доклады, и доклад Алименкова про No JMS, мне всё нравится… Но не всегда получается. И вот как только мне нужны транзакции на JMS+какую-нить БД — без JTA становится грустно. Эмулировать XA на редисе я так и не научился :(.
Вопрос в том, реально ли нужен JTA и стоит ли ради нее возиться с дерьмом JEE? Все остальное доступно по отдельности, лучше, удобоваримее, и легко подцепляется в виде библиотек.
— Во-первых, JTA создает ложную уверенность в atomicity. Если у Вас грохается ресурс на критической операции (сеть, машина, диски), транзакция становится unrecoverable. Внезапно, transaction manager перестает создавать другие транзакции, пока не будет решена проблема с грохнувшейся. Как это делается в конкретно взятом сервере — знают несколько человек в мире. Пока админ судорожно разбирается как откатить грохнувшуюся транзакцию, где подправить какие данные, работа стоИт.
— Во-вторых, впринципе невозможно создать надежную координированную работу нескольких удаленных систем (теорема CAP). Можно лишь немного приблизить работу, исходя из неочевидных предположений, например, когда сеть и железо более-менее надежно, вероятность сбоя при координированном коммите ничтожно мала. JTA неявно скрывает это, вселяя ложную уверенность в надежности.
— В-третьих, JMS без транзакции имеет ручной ACK, который является аналогом коммита. При этом брокер считает месседж обработанным и удаляет из очереди. Поэтому сначала делаем процессинг месседжа, коммит транзакции в DB, а потом ручками посылаем ACK брокеру. При такой структуре программист уже обязан въявную подумать, что случится, если на ACK грохнется ресурс. JMS в этом случае попробует еще раз прислать сообщение. Обычное решение — вести контроль дубликатов: сохранять в базе данных ID уже обработаных месседжей.
Как вариант, можно минимизировать риски от сбоя сети, если поднимать локально на каждый instance приложения embedded брокер, а затем связывать их в кластер. Сообщения надежно (если нет сбоя железа) отдаются и принимаются только от локального брокера, который уже в свою очередь занимается их пересылкой по сети.
Если так нужен JTA, то есть JBoss Transactions, или Atomikos. Оба интегрируются в Spring. Но в любом случае, JTA — это не панацея, а скорей вред.
— Во-первых, JTA создает ложную уверенность в atomicity. Если у Вас грохается ресурс на критической операции (сеть, машина, диски), транзакция становится unrecoverable. Внезапно, transaction manager перестает создавать другие транзакции, пока не будет решена проблема с грохнувшейся. Как это делается в конкретно взятом сервере — знают несколько человек в мире. Пока админ судорожно разбирается как откатить грохнувшуюся транзакцию, где подправить какие данные, работа стоИт.
— Во-вторых, впринципе невозможно создать надежную координированную работу нескольких удаленных систем (теорема CAP). Можно лишь немного приблизить работу, исходя из неочевидных предположений, например, когда сеть и железо более-менее надежно, вероятность сбоя при координированном коммите ничтожно мала. JTA неявно скрывает это, вселяя ложную уверенность в надежности.
— В-третьих, JMS без транзакции имеет ручной ACK, который является аналогом коммита. При этом брокер считает месседж обработанным и удаляет из очереди. Поэтому сначала делаем процессинг месседжа, коммит транзакции в DB, а потом ручками посылаем ACK брокеру. При такой структуре программист уже обязан въявную подумать, что случится, если на ACK грохнется ресурс. JMS в этом случае попробует еще раз прислать сообщение. Обычное решение — вести контроль дубликатов: сохранять в базе данных ID уже обработаных месседжей.
Как вариант, можно минимизировать риски от сбоя сети, если поднимать локально на каждый instance приложения embedded брокер, а затем связывать их в кластер. Сообщения надежно (если нет сбоя железа) отдаются и принимаются только от локального брокера, который уже в свою очередь занимается их пересылкой по сети.
Если так нужен JTA, то есть JBoss Transactions, или Atomikos. Оба интегрируются в Spring. Но в любом случае, JTA — это не панацея, а скорей вред.
Как минимум с JTA мы уверены в БД. Все вменяемые БД поддерживают двухфазный коммит. Так что в БД мы более-менее уверены, это обычно самое главное. Насчёт сообщений — они могут дублироваться и теряться. Как правило лучше пусть дублируются. В любом случае констрейнты в БД не дадут нам сотворить дикого ада. При этом если мы прочли сообщение из очереди, записали что-то в БД и упали — в БД ничего не запишется, сообщение уйдёт на ределивери. И это классные гарантии, которые нужны в распределённых больших системах. Я не специалист, но мне говорили, что у атомикоса есть какие-то ограничения по перерегистрации ресурсов.
Все, что Вы описали, делается быстрее и надежней без JTA. Любая БД всегда поддерживает обычные (локальные) транзакции. Случай, когда нужно обращаться (а именно апдейтить) сразу несколько БД довольно редок, и как правило говорит о плохой архитектуре. В этом случае лучше разделить апдейты разных БД в разные транзакции, а иногда даже делать это асинхронно при помощи того же JMS.
JTA именно дает гарантии, что сообщение не будет продублировано или потеряно, а обработано атомарно вместе с апдейтом БД. В случае, если двухфазный коммит фейлится на второй фазе (да, такое бывает!), то отваливается весь TransactionManager, и будет терпеливо ждать, пока его не починят ручками, и не подправят данные. А это реальный геморрой, особенно в случае нескольких БД.
Без JTA с ручным JMS acknowledgement (ACK) худшее, что может случиться — это когда выполнился коммит в БД, но система свалилась на посылке ACK брокеру. В этом случае случится ределивери (при настроеной персистенции), и возможны дубликаты, которые могут быть проконтролированы отдельно той же БД.
Так что польза от JTA достаточно сомнительная: они тяжелые, медленные, сложнонастраиваемые (в Weblogic 100+ настроек), сложнотестируемые и как правило глючные. В подавляющем большинстве случаев их использование неоправдано поставленной задачей.
JTA именно дает гарантии, что сообщение не будет продублировано или потеряно, а обработано атомарно вместе с апдейтом БД. В случае, если двухфазный коммит фейлится на второй фазе (да, такое бывает!), то отваливается весь TransactionManager, и будет терпеливо ждать, пока его не починят ручками, и не подправят данные. А это реальный геморрой, особенно в случае нескольких БД.
Без JTA с ручным JMS acknowledgement (ACK) худшее, что может случиться — это когда выполнился коммит в БД, но система свалилась на посылке ACK брокеру. В этом случае случится ределивери (при настроеной персистенции), и возможны дубликаты, которые могут быть проконтролированы отдельно той же БД.
Так что польза от JTA достаточно сомнительная: они тяжелые, медленные, сложнонастраиваемые (в Weblogic 100+ настроек), сложнотестируемые и как правило глючные. В подавляющем большинстве случаев их использование неоправдано поставленной задачей.
Ну мы на wildfly живём, у него достаточно просто всё. И да, в моём мире большой многокомпонентной системы, которая разворачивается уже, вроде бы, на 50 серверах, коммит в несколько БД и работу с JMS в одной транзакции как минимум в двух местах приходится использовать. Мы думали над тем, чтобы не делать всё в одной транзакции, но поняли что не можем себе этого позволить. Есть части, где консистентность данных критична.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Антон Кекс: Как нам спасти Java?