Вышел JBoss 5.0.0

> Лок ты сам придумал - нет никакого лока повторяю.

нет, я видел - как дб2 например - локает от того момента когда пошла транзакция (con.setAutocommit(false)) и если код зависает в середине - никто не может даже прочитать из таблицы: все отдыхают. Это зависит от уровня изоляции, конечно, но как правило анализом долго не парятся и делают один наиболее консервативный уровень - что есть катастрофа.
Нет - такие вещи надо делать в базе (ХП), а не в жаве.

Меньше транзакций - лучше. Идеально - всё превратить в машину состояний и обрабатывать неконсистентнные состояния (оставшиеся после жёсткой перезагрузки).

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

Этот консервативный уровень называется serializable.
То есть ты наесжаешь на JTA из-за идиотов которые не понимают нефига про уровени транзакций? Железный аргумент - в опровержение эффективности технологии можно привести любое количество идиотов которые ей пользоваться не умеют.

>Нет - такие вещи надо делать в базе (ХП), а не в жаве.

А там что serializable по другому работает или что?

Цирк на проводе.

> Это пять балов - ты по сути вообще не понимаешь что такое транзакция. Обясню на пальцах: есть две операции A и B и они должны быть выполнены или обе или ни одной. Слететь может _любая_. Доступно? Читать определение ACID до прозрения.

я понимаю это лучше тебя. я не желаю всё делать SERIALIZED

> Вот что ты ответил - ты сделал комит в базу и если он прошел - послал мессадж. Если мессадж не прошел - ты в торбе - в базе данных комит и паралелльные системы это уже увидели - состояние неоткатываемо в общем случае безотносительно всяких там undu которые ты напишешь.

месседж придёт по-определению, чуть позже. а мой dirty-read способствует более эффективному решению.

>я понимаю это лучше тебя. я не желаю всё делать SERIALIZED

Бля это трындец. Где связь между atomicity и serialized?

>месседж придёт по-определению, чуть позже.

Трындец. Через libastral.

я наезжаю на возможность делать локи из жабы и из удалённого процесса (и давать возможность жаба-программерам решать). База должна предоставить ХП АПИ и только ДБА знает - что и как он поменяет для оптимизаций. Может денормализует всё. Программирование транзакций - удел программистов БД

>Бля это трындец. Где связь между atomicity и serialized?

а чем гарантируется atomicity?
ты всё кладёшь в транзакцию. и ты сам не хочешь делать DIRTY-READ.
наверняка поставишь SERIALIZED.
вот база всё (на уровне таблицы) и локнет.
читаем transaction-isolation levels до просветления.

>Программирование транзакций - удел программистов БД

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

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

>а чем гарантируется atomicity?

Вообще-то, транзакции — это и есть механизм обеспечения atomicity.

>ты всё кладёшь в транзакцию. и ты сам не хочешь делать DIRTY-READ. наверняка поставишь SERIALIZED.

Причём тут это? Это — уровни изоляции, совсем другая песня, нежели atomicity.

>читаем transaction-isolation levels до просветления.

Вот-вот. Читай.

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

И, кстати, DIRTY-READ — это спецэффект, а не уровень изоляции. Ты, наверное, имел ввиду READ UNCOMMITED?

обычо аппликация работает с одной базой. Очень редко - с несколькими (с 2). Как правило - только лукапы (не апдейт) - из второй или 3й.

>Я говорю о случаях когда это не представляется. Типичный случай для индустрии

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

> И, кстати, DIRTY-READ — это спецэффект, а не уровень изоляции. Ты, наверное, имел ввиду READ UNCOMMITED?

да

> так вот я и говорю - ебей который ты приводишь как пример правильного масштабирования - на вебсфере и масштабируется.

я бы не сказал что он "на вебсфере масштабируется". Когда вы на чем-то масштабируетесь, это значит что оно у вас одно, вы его только наращиваете ("добавляете узлы в кластер" как говорил выше по треду блондин). А у ебея, читаем:

15,000 application servers, all J2EE. About 100 groups of functionality aka "apps". Notion of a "pool": "all the machines that deal with selling"...

App servers do not talk to each other -- strict layering of architecture Use what you like and toss what you don't need. Ebay didn't feel compelled to use full blown J2EE stack. They liked Java and Servlets so that's all they used. You don't have to buy into any framework completely. Just use what works for you.

используются кучи *отдельных* АПП-серверов. а не один супермегааппсервер запущенный на супермегакластере. Распределенных транзакций (которые вы нам на предыдущих страницах пытались продать как killer feature апп-сервера) избегают.

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

Но то, что просто использование апп-сервера (websphere той же) обеспечит вам автоматическое беспроблемное масштабирование - нету такого.

Берем java'у, и начинаем масштабировать почти так как масштабируют решения на PHP.

по вопросу использьзования XП vs распределенные транзакции - тут я с анонимусом расхожусь кстати. и с локами куда-то он не туда...

> а чем гарантируется atomicity?

Ты вообще понимаешь что такое атомарноть и какой физический смымсл 
имеют уровни изоляции? Что именно они изолируют? 

>ты всё кладёшь в транзакцию. и ты сам не хочешь делать DIRTY-READ. 

И при чем тут АТОМАРНОСТЬ!?

>наверняка поставишь SERIALIZED.

Пока ты не осилил понятие ACID - даже не пробуй заниматься телепатией. 

>вот база всё (на уровне таблицы) и локнет.

Ох как ты меня устал:

На:

Connection1:

test=# CREATE TABLE test (a serial, b text);
NOTICE:  CREATE TABLE will create implicit sequence "test_a_seq" for serial column "test.a"
CREATE TABLE
test=# INSERT INTO test (b) values ('a1');
INSERT 0 1
test=# INSERT INTO test (b) values ('a2');
INSERT 0 1
test=# INSERT INTO test (b) values ('a3');
INSERT 0 1
test=# select * from test;
 a | b
---+----
 1 | a1
 2 | a2
 3 | a3
(3 rows)

test=# BEGIN TRANSACTION ;
BEGIN
test=# SET transaction_isolation TO SERIALIZABLE;
SET
test=# UPDATE test SET b = 'updated 1' WHERE a = 1;
UPDATE 1

Connection2:

test=# SELECT * from test;
 a | b
---+----
 1 | a1
 2 | a2
 3 | a3
(3 rows)

test=# BEGIN TRANSACTION ;
BEGIN
test=# SET transaction_isolation TO SERIALIZABLE;
SET
test=# UPDATE test SET b = 'updated 2-1' WHERE a = 2;
UPDATE 1
test=# COMMIT TRANSACTION ;
COMMIT
test=# select * from test;
 a |      b
---+-------------
 1 | a1
 3 | a3
 2 | updated 2-1
(3 rows)

Conection1:

test=# commit;
COMMIT

Connection2:

test=# select * from test;
 a |      b
---+-------------
 3 | a3
 1 | updated 1
 2 | updated 2-1
(3 rows)



===============

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

PS: ЗАпарили уже экперты по третьем мускулю.

http://www.addsimplicity.com/downloads/eBaySDForum2006-11-29.pdf

>>на rsdn пару лет назад было точно так же... это диагноз :)

>Вообще-то это то Extend из 3e микрософта. ТАм где .NET с .NET дружиться а не с .NET не очень - потому что ганяет даные которые WSDL не описаны. ЗА это надой яца разрабам отрывать.

На русском языке такое, когда WSDL "для видимости" делается, называется "ранним связыванием" клиента с кодом сервера — WSDL по сути дела не используется, а клиент использует код сервера для биндинга к его методам.

Яйца отрывать однозначно.

> http://www.addsimplicity.com/downloads/eBaySDForum2006-11-29.pdf

если наводящие вопросы про локи не помогли - из ебея:

"Absolutely no client side transactions
- Single database transactions managed through amonymous PL/SQL blocks.
- No distributed transactions

How do we pull it off?
- Careful ordering of DB operations
- Recovery through
...

Rationale
-Avoid deadlocks"


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

И я видел не один проект, заваливаемый ж2ее девелоперами, - из-за страшных дедлоков (когда применяются транзакции - всё согласно рекламкам). Но дедлоки просто появляются - не смотря на то что вам этого не хочется. После чего всех ж2ее выгоняют и делают всё по-старинке.

кстати дб2 и оракле - очень разные - в политике локов ;)

ладно, считай что я не знаю что такое ACID - если так легче.

после десятка лет опыта с реально большими деплойментами - ты меня поймёшь (если ж2ее ещё будет жива)

> А еще Академия Наук подписалась за 4 миллиарда руб. сделать аналог JBoss для нужд МВД.

Ссылку?

> Значит, они переделали. Пару лет назад там точно был Tomcat.

eBay переделывает всё раз в два года. Это не показатель. Бьюсь об заклад, через два года там будет DotNET.

>Ссылку?

http://10.7.0.7

>eBay переделывает всё раз в два года. Это не показатель. Бьюсь об заклад, через два года там будет DotNET.

Из-за true enterprise фишки TCO aka Tail Call Optimization? Сомневаюсь

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

>Куча ява дрочеров опять поналезло чтобы спорить до хрипоты. А кому завтра на работу/универ/школу... их это не волнует главно опять проспорить до 5 утра, фанатики, что тут сказать...

Когда в Москве три часа дня, в Петропавловске-Камчатском — полночь.

Учи географию часовых поясов.

>А unix-way утилита для делания таких вызовов есть? Для cgi - wget и curl, а soap-вызов чем сделать? ( я понимаю что curl'ом вообще-то можно, но хотелось бы что-то более заточенное... мы же не пользуемся одним nс для всех нужд..)

На перле при помощи soap-lite модуля на раз +). Кстати, на перле соап запросы писать намного более удобно и получает намного красивее, чем на java.

> НАверное потому что логику тогда надо будет писать в этом sql сервере - что совсем несмешно?

Именно так, всю логику писать на этом sql сервере.

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

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

В принципе, менеджеры распределенных транзакций доступны и отдельными компонентами. Например, Atomikos: http://www.atomikos.com/Main/TransactionsEssentials

Просто в комбайне оно как бы всё сразу работает. Но я встречал системы, где нужные компоненты собраны самостоятельно, на базе Spring Framework.

По распределенным транзакциям есть спецификация: http://en.wikipedia.org/wiki/X/Open_XA

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

логику на жабке... ты лучше попробуй на php напиши многопоточное вебприложение без извращений (например для организации ожидания ответа 3ей системы).

И кому нынче EJB потребны? Уже 2 года как перешел на Spring и доволен, что избавился от таких тормозов, как EJB.

>какая глупость! > почему мой CGI скрипт на перле, скажем, не веб-сервис? Почему тогда тот-же результат, возвращаемый сервлетом - не веб-сервис? ПХП? > Не B2B? не C2B?

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

>почему мой CGI скрипт на перле, скажем, не веб-сервис? Почему тогда тот-же результат, возвращаемый сервлетом - не веб-сервис? ПХП?

Дело в том, что для многих веб сервис == SOAP веб сервис.

О том, что бывают и другие веб-сервисы (хотя бы построенные по принципу REST), им неведомо.

Все не читал, но скажу так. По своему опыту пришло осознание, что всякие апп-сервера не нужны. Пока JEE5 3 года принимали, оно уже морально устарело. Гараздо проще все делать embeddable решениями. Например запускать все из Spring. Сделать JMX мониторинг или запускать Jetty из спринга как 2 пальца об асфальт, и нет никаких проблем с класслоадерами, когда пользуешься серверами и версии библитоек сервера расходяться с версиями в твоем приложении. Итого собирается обычный линуксовый спринговый демон, с пом. http://vafer.org/projects/jdeb/ и деплоится с полпинка. JTA так же легко встроить. можно взять тот же JOTM или JBOSS Transactions.

Теперь по поводу маштабируемости. маштабируемость с пом. JEE это миф! Для этого сейчас есть другие решения как: Terracotta, GridGain, GigaSpaces и тому подобные штуки!

EJB - не нужен. Оно все это ща нужно, только что бы поддерживать кучу старого, плохнопахнущего г....

Дf и еще про SOAP. SOAP - это оверхед. Не зря ща недавно была принята спецификация JAX-RS. И о чудо!!! Ее приняли всего-то за год!!!!

В треде прозвучали мысли что J2EE - говно, в частности JBoss, EJB и пр. На какие технологии стоит ориентироваться начинающему java-разработчику?

> В треде прозвучали мысли что J2EE - говно, в частности JBoss, EJB и пр. На какие технологии стоит ориентироваться начинающему java-разработчику?

на лисп, возможно на эрланг :)

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

>В треде прозвучали мысли что J2EE - говно, в частности JBoss, EJB и пр. На какие технологии стоит ориентироваться начинающему java-разработчику?

Изучай Spring, REST, и смотри в сторону GRID решений, за этим будущее.

Своетую всем послушать этого человека, до полного просветелния http://www.theserverside.com/tt/knowledgecenter/index.tss

Тут уже писали про этот подкаст. Очень грамотные вещи говорит

>на лисп, возможно на эрланг :)

Кстати по поводу эрлаг У этой платформы очень клссная идея масштабируемости, похоже на Terracotta. Кластеризация на уровне языка, а не приложения. Хотел использовать http://www.rabbitmq.com вместо ActiveMQ, но к сожалению там еще фэйловер не доделан. Пришлось отказаться.

Кстати новая идея с AMQP вместо JMS тоже интересная. Похожая на REST вместо SOAP

Вот из RabbitMQ FAQ

Q. How does clustering work?

A. RabbitMQ's current clustering mechanisms are built around Erlang's native support for reliable distributed programming. This is a deeply sophisticated framework, implemented at the language and virtual-machine level.

Some of the unique points about Erlang's networking and distribution model are: it scales to hundreds of thousands of parallel processes ("green threads") within a single virtual machine, bounded only by available memory; the failure model for local inter-process communication (IPC) is the same as that for distributed IPC, making the transition from non-distributed to distributed code very smooth; binary pattern-matching constructs within the language ensure straightforward and efficient translation between wire-level encodings and internal Erlang data structures; finally, the OTP libraries shipped with the Erlang distribution include the notion of a supervisor/worker relationship, where supervisor processes monitor and restart worker processes under their control, making management of the entire process hierarchy within a server deterministic and automatic.

Within an Erlang node cluster, Erlang's native high-speed messaging is used to provide an efficient way of distributing work across the cluster. Individual AMQP clients connect to machines within the cluster, and Erlang's distributed routing database routes AMQP messages to the appropriate endpoints.

> Within an Erlang node cluster, Erlang's native high-speed messaging is used to provide an efficient way of distributing work across the cluster. Individual AMQP clients connect to machines within the cluster, and Erlang's distributed routing database routes AMQP messages to the appropriate endpoints.

дак так бы и говорил, что это по-большому счёту адаптер для жабы для общения с эрланговым кластером. Сервера-то всё равно надо на эрланге писать.

>Сервера-то всё равно надо на эрланге писать.

Я не заморачиваюсь, что какой-то компонент может быть не на Java. Если есть решение и оно отлично работающее, то его стоит использовать. Вот я использую гном, но не испытываю никакой аллергии запуская KDE или QT приложения

>дак так бы и говорил, что это по-большому счёту адаптер для жабы для общения с эрланговым кластером. Сервера-то всё равно надо на эрланге писать.

Почему? RabbitMQ — это только брокер сообщений, т.е по сути — доставка (со всякими энтерпрайз фишками, типа балансировки, durability, и.т.д). А уже генераторы/потребители сообщений могут реализовываться на любом другом языке.

> на лисп, возможно на эрланг :)

И что потом? Зарабатывать на жизнь флудом на лоре?

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

Cобрать всех любителей Хаскеля и посадить на самолёт(да, я думаю одного хватит) - никто не заметит как он упадёт. В мире миллионы программистов и как минимум 3/4 из них программирует на C/C++/Java/C#, поэтому если какой язык и будет следующим, то похож он будет на них.

Lisp/Erlang - они хороши для очень ограниченного класса вещей(meta-programming/concurrency), и мы скорее увидим растущую популярность Jetbrains MPS, применения Reflection, Terracota или Actor Model на JVM. Да за примерами далеко ходить не надо - посмотрите на JavaScript: Web куда более популярная потребность чем m/c, да и JavaScript отличается от нынешних языков лишь тем, что строится на прототипах - но всё равно - над нам строят абстранкции к более привычным языкам: Pyjamas, GWT, RJS, Objective-J.

В западных блогах прямо дрочат на polyglot programming(в основном консалтеры конечно), это может быть и применимо для top 5% программистов, которые учат по языку в год и комфортно чувствуют себя в нескольких языках - но никакой менеджер вам не разрешит писать проект на Erlang, если поддержать его сможет лишь 1% из ищущих работу.

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

> И что потом? Зарабатывать на жизнь флудом на лоре?

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

Ага. Тем более, что вон выше пример брокера RabbitMQ, где Erlang _спрятан_.

> Cобрать всех любителей Хаскеля и посадить на самолёт - никто не заметит как он упадёт <...> C/C++/Java/C#, поэтому если какой язык и будет следующим, то похож он будет на них.

Надо отличать нетрадиционный синтаксис от интересных идей, которые будут потом реализованы и в традиционном С-подобном синтаксисе.

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

Я не спорю, но я думаю после 2-3 лет на Java он дойдёт до этого сам - и SICP посмотрит, и с Erlang разберётся - тем интересных много, сам выберет: может в графику потянет или в графы. Другое дело, что сейчас то это ему зачем?

А то приходит молодняк на собеседования, как JVM классы грузит не в курсе - зато про JRuby/Clojure/Scala обязательно в блогах читал. Интернет нынче могуч - попробовать можно что угодно, но вот многие начинают с того, что разбрасываются, и с уверенности, что перейти с их Ruby/PHP на Java проще пареной репы.

> на лисп, возможно на эрланг :)

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

> Надо отличать нетрадиционный синтаксис от интересных идей, которые будут потом реализованы и в традиционном С-подобном синтаксисе.

Это было в последнем предложении. http://antilamer.livejournal.com/253917.html - интересные идеи FP в Java, ну не говоря уже о Scala, хотя в ней слишком много хороших идей.

> А то приходит молодняк на собеседования, как JVM классы грузит не в курсе - зато про JRuby/Clojure/Scala обязательно в блогах читал. Интернет нынче могуч - попробовать можно что угодно, но вот многие начинают с того, что разбрасываются, и с уверенности, что перейти с их Ruby/PHP на Java проще пареной репы.

я вот тоже не в курсе как JVM грузит классы =) но не думаю что там какое-то сакральное знание и оно сильно сложнее загрузки той же shared либы в память (есть подозрение что ещё и проще).

Просто есть проблема - если человек начинает усиленно изучать только жабу, то он на ней и зацикливается. В итоге имеем людей с ЖГМ типа Bioreactor.

А вообще жаба как язык изучается за неделю (при условии что знаком с ООП), а вот всяких монструозных библиотек у неё просто уйма.

> Это все хорошо и попутно посматривается, конечно же. Но меня интересует другое. В жабамире нынче столько баззвордов, что неискушенному программисту легко сойти с ума, так вот, на какие из них стоит обратить внимание, что наиболее перспективно?

JEE - читайте TSS & InfoQ, и не разбрасывайтесь по сторонам. Проводником является Spring - учите его, в нём есть интеграция со всем, что вам может понадобиться.

Ну начинать естественно с Java Tutorial на sun.com, JEE Tutorial тоже можно прочитать, хотя не все его части являются де-факто стандартом.

> Ну начинать естественно с Java Tutorial

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

> А вообще жаба как язык изучается за неделю (при условии что знаком с ООП), а вот всяких монструозных библиотек у неё просто уйма.

Знаете, есть такая книжка Effective Java от Блоха, а ещё есть всякие паттерны, puzzles. На Java можно писать плохо, а можно с продуктивностью Python. Это всё приходит не сразу и не без усилий.

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