увы. джаву не знаю ваапще. рекомендую обратицца к 6a6ep@lj - он тожэ принцыпиальный йобнутый на голаву юниксоид. не откажет ф помащи, ему самому интересна, мы этот вапросиц ужжэ както подымали

Угу, спасиб.
Обращусь с утра.
А щас я уже думаю спать атправица.
Ф гораде Питере 3:19AM.

спокно тахда, я вот фсьо копирайты "интролигатора" ф парядак привести
стараюсь

Звони/аськай. Я теперича сунь сертифайд, мне всё можно :)

Даю любой ответ на любой вопрос.

Но EJB тебе там нах не надо.

Я так и знал, что кто-нибудь это скажет.
А за что мне тогда денег срубать, если не за EJB? :))))))))))

Просто бин — это запрос-ориентированный компонент: спросили — поднялся, ответил, уснул.
И никакого стандартного механизма для того, чтобы что-то "постоянно крутилось", в иджыбях нет.

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

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

В общем, стучись в аську =)

можно, и называется это stateful beans (бины с состоянием), которые сохраняют свое состояние напротыжении или жизни контейнера, или пока сами не умирают (во всяком случае в ЖБоссе по-моему так все работает).

Уфф... Сударь, вы понимаете разницу между "живым" и "активным"?

весьма да, сэр :)

Ну а что ж вы тогда дурью маетесь?

я мысли излагаю.

эта, stateful bean есть - он живет до тех пор, пока контейнер ему не скажет умереть ,или пока сам не решит умереть.

И поднять из бизнес-метода свой трэд никто не запрещал, другое дело что в спецификацию EJB это не очень всунуто (EJB 3.0 не видел), но блин голова на что дадена? :)

Я не сказал "умер" — я сказал "уснул". Разница есть?
Про нитку я писал. К слову: поднимать треды в бинах таки запрещено (EJB 1.1, section 18.1.2; EJB 2.1, section 25.1.2).
Делали мы это всё. К EJB данная задача не относится никак. Вообще.

А в голову я ем.

то что не относится - это и ежу понятно :)
Раз человек хочет непременно ЕЖБ и непременно с нитями - то пуркуа бы и не па?
В стэйтфуле сохранять референс на нить, в которой что-то делается (эту нить хоть демонизировать) , и при запросе смотреть данные оттуда. В Спеке нет - согласен, но опять-таки я не думаю что контейнер рухнеть из-за какой-то нити, о которой он даже и не в курсе.

Поясняю: я знаю, как это сделать. И я знаю, что нужно человеку.

Дальше, "контейнер не рухнет" и "не запрещено" — существенно разные вещи, не находите?

да рад за вас ,ей богу. Или вы клон Решетова из RU.JAVA? Кроме ваших мнений может существовать большое количество других, не менее правильных, вы не находите?

Нахожу. Но в вашем мнении есть фактические ошибки. И я бы не хотел, чтобы эти ошибки перекочевали в чью-либо архитектуру.

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

собственно скелет такой

public class someWorker extends Thread {
private static someWorker instance = null;

private someWorker() {
//инициализация
}

public static someWorker getInstance {
if (instance == null) {
instance = new someWorker();
instance.start();
}
return instance;
}

public void run() {
//делать что надо
}

public чего-там-надо-вернуть getState() {
synchronized (instance) {
//че-то сделать
}
return чего-там-надо;
}
}


Где здесь принципиальная ашипка, коллега?

Уффф... Я не про синглтон и не про нитку. Я про "не запрещено" и прочие пассажи.

К слову, синглтон ваш не thread-safe ни разу. Да и его рождением и смертью вы управлять не сможете. Никакого там "со старта контейнера".

И ещё раз повторяю: всё это просто никому не нужно. Парить мозги заказчику можно более гуманно, а если мозги не парить, тогда EJB надо просто выкинуть.

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

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

Леш, вариант заселить мою аппликуху в кота тоже не тред-сэйф не разу.
И вообще я боюсь в кота что-то свое заселять, там потоки запускаются и останавливаются как бык посцал.
Я вот думаю за простой RMI теперь. Кстати, а SOAP в Жабе есть уже?

Сашка, ты маньяк. Нах тебе RMI? Нах тебе вообще всё это счастье?
Thread-safe или нет — зависит не от кота, а от кода, который нитки разводит. А тут он кривой. Разве я могу не пнуть за кривой код? :)

Нитку в кота — тоже геморрой, но не такой большой. Там есть честный listener старта и смерти контекста, по ним хорошо подниматься и убиваться. Но попробуй всё-таки на cron повеситься. Надёжнее всё равно не будет. А кота тебе придётся поднять, чтобы пользовательский интерфейс сделать.

SOAP умеет, завтра спрошу наших, какая реализация попрямее :)

К слову, синглтон ваш не thread-safe ни разу. Да и его рождением и смертью вы управлять не сможете. Никакого там "со старта контейнера".

Во-первых, вполне себе трэд-сейф (докажите обратное).

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

И ещё раз повторяю: всё это просто никому не нужно. Парить мозги заказчику можно более гуманно, а если мозги не парить, тогда EJB надо просто выкинуть.

Все эти тонкости кастомеру вообще знать не надо :) А так - подписываюсь, ЕЖБ мало где себя оправдывает, если конечно не пишется приложения для завода командой из 100 человек.

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

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

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

Ну извините, что задел вашу нежную душу. Должного мне отдавать не надо. И см пункт выше. А про мою "глупость" позвольте рассуждать моему тим-лидеру или архитектору (вы не возражаете?).

Доказать обратное просто: у вас публичный метод getInstance не синхронизирован, у вас переменная инициализируется раньше, чем инициализируется объект, на который она указывает. Вы вообще писали многопоточные приложения когда-нибудь? Или вы считаете, что никто кроме вас не вызовет getInstance?

Я уже давал ссылки на спецификацию. Повторить или соизволите прочитать сами?

Доказать обратное просто: у вас публичный метод getInstance не синхронизирован, у вас переменная инициализируется раньше, чем инициализируется объект, на который она указывает. Вы вообще писали многопоточные приложения когда-нибудь? Или вы считаете, что никто кроме вас не вызовет getInstance?

в данном конкретном случае вы правы, ключевое слово "скелет" тоже не для красоты было сказано.

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

Кроме того, давайте от придирок к коду (вы еще придеритесь к тому, что он вообще не скомпилируется) перейдем к основному вопросу - чем данный скелет (при условии представления его как thread-safe) выпадает из спецификации EJB? Точнее не так - чем он ей противоречит? И почему нельзя его использовать?

Желательно без просто ссылок (PDF со спекой у меня есть и в е-виде, и в твердой копии), а своими словами с пояснениями.

В данном конкретном случае вы таки признали ошибку. Ура.

С нитками и синглтонами очень просто: вам запрещено использовать статик поля и вам запрещено создавать нити. Мотивация: у вас не одна JVM, не один класслоадер, и не один хост; планировать процессы должен контейнер, а не вы.

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

Не признавать ошибки - это глупо, тем более такие очевидные :)

Насчет остального - я вырос из возраста ,когда говорят "я аккуратно". Но в конкретном данном случае это, судя по всему, таки неважно. :)

Надеюсь на этом мы и закончим, потому что переубеждать меня можно только с примером приложения, где это реализовано и это плохо, вас, судя по всему, тем же - приложением, где это реализовано, и это хорошо. :) На руках у меня ничего подобного для ЖБосса или УёбЛожки нет, посему мне добавить нечего.

Я участвовал в проекте, где всё это было реализовывано, и всё это было хорошо. Но там просто по-другому было не сделать.

А в случае сферического приложения в вакууме, равно как и в данном конкретном случае — за такие решения надо отрубать руки. Ибо класть на спеку "просто так" —глупо. А глупость должна быть наказана.

Вот теперь можно заканчивать.

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

Вот это уже разумнее, чем объяснять мне как синглтоны пишутся :)

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

А крон при всей своей непортабельности надёжнее.

да ну, у меня сертификатофф нет - куда уж нам :)

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

Вариант с сокетами привлекателен портабельностью - сокеты они и в африке(Виндоуз) сокеты.

А-а, сертификат... Я его ещё два с полтиной года назад мог получить. Жаба тогда задушила. А тут просто деньги нашлись, вот и исполнил давнюю мечту. Вообще люблю всяческие игрушки, значки, сертификатики. Бессмысленно — но приятно.

К делу: если юзеров мало, то нас и нагрузка не сильно волнует :) "Левость" приложения — вопрос исключительно субъективный, и потому несущественный. А пинать контейнеры снаружи — дело нехитрое: для EJB всё написано за нас, для JSP/Servlets достаточно придумать, что и в каком формате мы запихнём в POST. Так что никакой привязки к конкретному контейнеру нет. JSP/Servlets тут предпочтительнее, потому как всё равно чем-то надо отдавать интерфейс, так что всё уже под рукой. Да и ServletContext отлично подойдёт для временного склада данных.

Весь вопрос в объёмах. Большой объём проще опрашивать, малый проще хранить у себя. Но большой объём я бы вообще в базу свалил, так что моим выбором были бы Tomcat и cron task. Вместо cron task можно использовать постоянно крутящуюся JVM — что больше нравится.

Можно, конечно, использовать raw sockets, можно RMI, но всё это либо неоправданный геморрой, либо стрельба из пушки по воробьям. (EJB — это стрельба по воробьям ядрёной бомбой, но этот вариант хотя бы продать можно).

Решетова?
Какого Решетова, Димы?
Если Димы, то я с ним работал, да он и мой ЖЖ читает. :)

(думает), не ,того вроде Юрием звали, он там еще какой-то свой проект уююками по пол-метра постил. Редкий кадр, абсолютно невменяемый :)

Юрий, Юрий. Он написал лучший энджин всех времён и народов.

К слову — гарантированное время жизни стэйтфул бина равно клиентской сессии. Кто эту нитку пасти будет?

читаем про Singleton, думаем, краснеем.

Вот ведь вежливый человек! Друго бы нахуй послал.

Скажите, вы действительно думаете, что я не знаком с книгой GoF?

я таких далекоидущих предположений не делаю. Я кстати тоже читал много книжек, знания из которых никогда не применял. До архитектора не дорос, но Java Patterns от С. Стелтинга и О. Маассена являются настольной книгой и справочником. Ы?

А-а.

.Net Web Services

Щас это моднее

Майкрософт презираю.

Хм. А откуда познания в COM?
Сан еще хуже - они запроданцы Майкрософта.

Не хотите Майкрософт, можно юзать .Net от http://www.go-mono.com на линуксе, если конечно нет предубеждений против Новелла.

Виноват!
На Линуксе

Ближе к делу: JBoss 4.0DR3 умеет EJB 2.1 Timer Service, как раз тебе подойдёт. Но DR означает "Developer's Release," а Developer's Release is not intended for production, please download the latest 3.2.x release instead.

Так что если клиент не побоицца, то прокатит.

Если побоится — вешай cron task, из кронтаска пинай своих котят, и сваливай данные JBoss-у. Он тут будет просто для галочки, но зато условие задачи будет выполнено. Тогда тебе хватит одного EJB со всеми необходимыми методами, либо двух — один EJB будет получать данные от крона, один отдавать результаты JSP/Servlet-контейнеру. Все бины Session, Stateless.

Но, опять же, кота с cron task-ом тут хватит за глаза и за уши.

http://www.junlu.com/msg/69415.html

Неплохая статья про Timer Service лежит тут: http://www.theserverside.com/articles/article.tss?l=MonsonHaefel-Column4

насколько я понял, человеку надо нечто ,что выполнялось бы непрерывно. А шедулер - это как бы что-то более другое.

Здесь мне подошел бы и шедулер.

А вы порассказывайте мне за паттерны, порассказывайте...

ISBN 5-8459-0339-4
ISBN 0-13-066190-2

За Core MySQL спасибо, посмотрю.

дааа, хорошо в Вильямсе списывают ISBN оригиналов :(

Общество ООО "ДорИнБуд" с 1994 г. успешно осуществляет высококачественные работы по асфальтированию дорог, территорий, площадок, тротуаров. Ради 17 лет выполнено огромное количество заказов, общество имеет безупречную репутацию и является надежным партнером. Все работы осуществляются высококвалифицированными, опытными специалистами, с применением современной строительной техники.

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

Будущий деятельности:

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

Мы выполняем работу бегло, качественно, в срок, даем гарантию. Работы выполняются в Киеве, Киевской области и других регионах Украины. Выполняем любые объемы работ. Предлагаем сотрудничество, как по подрядным работам, беспричинно и по субподряду.
[url=http://dorinbud.com.ua]Асфальтирование дорог в Киеве и Киевской области[/url]

Обращайтесь за консультацией по телефонам (044) 223-14-07,
(067) 465-44-05. Будем рады сотрудничеству с Вами.