Цитата(Souljah @ 3.11.2005, 13:02)

недавно читал cookbook из commons-command, там как раз решение для web описывается, стоит посмотреть

Вас из дас, и где это можно найти в нете? Или только бумажный вариант?

упс, перепутал.

commons-chain конечно

Цитата(Souljah @ 3.11.2005, 11:26)

я думал, имеются в виду еще некие сакральные "серверные потоки" - вроде нескольких экземпляров сервера в контексте одного приложения

Я понимаю. тебя смутила вот эта фраза:

Цитата(KostenkoSergey @ 31.10.2005, 18:19)

Экземпляр будет создан для отдельного потока сервера. (их число настраивается)

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

Цитата(pvo @ 3.11.2005, 11:33)

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

Это просто чудо, что ты тоже так думаешь, потому что тотальная сериализация - это такая чудовищная крамола, что никто про это даже и заикаться не смеет.

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

Why shouldn't we make the service() method synchronized?

Цитата

Meanwhile, the first thread finishes executing the service(...) method, so it releases the lock on the servlet instance. One of the other threads--not necessarily the second thread, so we'll say the eighth thread--awakens to find the servlet's lock available, so it requests the lock and starts processing the service(...) method. Meanwhile, the servlet container may be receiving other requests. It's possible that when the eighth thread (which was the second to execute the service(...) method) finishes, the thirty-fifth thread grabs the lock.

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

Потому что если бы ты хоть чуть-чуть умел соображать, то легко прикинул бы хер к носу: хорошо, по какому-то невероятному совпаданию в некий момент к нам вдруг ломанулись в едином порыве 35 юзеров. Ну и фигли? Поставим их в очередь, каждого обслужим за 20 ms, и никто не уйдет обиженным. Самому последнему придется ждать - страшно подумать - целых 0.7 секунды. Тебя бы, дятла, в сибирскую тайгу да на диалап, да дать задание подготовить обзор сайтов на народ.ру

Это про сериализацию. Про доступ из разных приложений цас отдельно напишу.

Это сообщение отредактировал(а) Stampede - 3.11.2005, 23:21

Цитата(pvo @ 3.11.2005, 11:33)

Например, у нас было несколько заказов, в которых с базой работают ( r/w/d ) 2 и более разных независимых приложений (не только веб приложений). Независимых - написанных разными людьми в разное время на разных языках и с использованием разных идеологий (ситуация не сильно хорошая, но довольно распростаненная у крупных рос. заказчиков). При этом в одной транзакции происходило довольно сложное изменение данных .... В общем, в такой ситуации синхронизация методов не спасает.

Да, действительно, тема интранета у нас осталась нераскрытой. От себя добавлю, что это не просто "довольно распространенная у крупных рос. заказчиков", а самая обычная - и в крупных, и в мелких, и в российских, и в нероссийских конторах ситуация.

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

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

В общем, тема тоже интересная

Stampede, у меня вопросина появилась, задал в соседней теме. Если нетрудно, хотел бы выслушать твоё мнение и, желательно, совет.
Особенно если он не будет касаться моей переквалификации )))

Цитата(chief39 @ 4.11.2005, 11:47)

Если нетрудно, хотел бы выслушать твоё мнение и, желательно, совет.

Готово.

Цитата(chief39 @ 4.11.2005, 11:47)

Особенно если он не будет касаться моей переквалификации

Плюс за чувство юмора

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

Цитата(Stampede @ 4.11.2005, 13:44)

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

Стараюсь...
Стыдно что не дочитал и не углядел.
Скоро ещё вопросов подкину.

Цитата(Stampede @ 3.11.2005, 21:07)

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

Собственно, так и делалось - синхронизация на уровне базы. Конечно, блокировались не целиком таблицы, а строки(мы использовали оракл). А для повышения скорости использовались хранимые процедуры - чтобы не гонять кучу select, update и прочего по сети. В некоторых случаях эти хранимые процедуры уже были, в некоторых приходилось их писать самим.

Цитата(Stampede @ 3.11.2005, 21:07)

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

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

Это сообщение отредактировал(а) pvo - 5.11.2005, 12:36

[QUOTE=Stampede,3.11.2005,  20:32]
Про барана вы это метко заметили. Только, извините, на барана вы сам как-то больше похожи.

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

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

В третьих, и в самых важных, тут что-то говорили про крутое оборудование и т.п. А что толку с крутого оборудования, если у вас запросы СЕРИАЛИЗУЮТСЯ? Ну поставь ты хоть 24 процессора, хоть 32 - работать-то будет один. С Сериализацией запросов вы не в состоянии обеспечить загрузку оборудования, это заведомо немасштабируемое решение. 
Настройка приложения - это решение задачи максимальной утилизации имеющихся вычислительных ресурсов, а подход с сериализацией - это декларация своей профнепригодности.

__________________

Автору треда: ну и пусть оно создаёт экземпляры классов на всякий запрос. Храните данные в сессии:

<% 
  javax.servlet.http.HttpSession s = request.getSession();
  Integer i;
  syncronyzed(s){
    i = (Integer)s.getAttribute("i");
    if(i==null) i=0;
    s.setAttribute("i",i+1);
  }

  out.write("hello "+String.valueOf(i++));  
%>

Добавлено @ 03:03 

А почему было не сделать обновление кеша по завершении транзакции?

Если в приложении есть кеш - очевидно многие читают одно и то же, а изменения происходят намного реже.
При изменении данных, каждый метод точно знает что он изменил, по этому перед коммитом сделанных изменений, он просто лочит кеш, делает коммит в базу, если ошибка - отпускает кеш, если нормально прошло - удаляет из кеша измененные записи и опять-таки отпускает кеш: первый, кто за измененными данными обратится, тот и будет их выкачивать. Ну и плюс механизм целостности предусмотреть: читатели должны вычитывать непротиворечивый набор данных, по оракловому же принципу, а писатели... С писателями oracle разберётся.

Иначе зачем вам сервер приложений? 

Это сообщение отредактировал(а) 3x3 - 20.9.2006, 03:05

3x3, неплохо, что поднял интересную тему из глубин веков, но вот про барана вспоминать точно не стоило.

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

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

Не будем далеко ходить за примерами. Вот что нам сообщают:



Особенно радует вот эта сентенция: "а остальные юзеры и вовсе лапу сосут пока первый высасывает данные". Поясняю для тех, кто "не в теме": как справедливо отметил гневный обличитель, загрузка страницы в общем случае включает в себя несколько циклов запрос-ответ. Сначала загружается собственно текст страницы (как правило, в формате HTML). Затем браузер парсит этот текст и обнаруживает, что страница содержит внешние подгружаемые элементы, такие как файлы стилей, скрипты, картинки и пр. Наконец, для каждого из этих элементов браузер шлет по отдельному GET-запросу.

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

• Прежде всего: подгружаемые элементы - это в подавляющем большинстве случаев статические ресурсы. Чтобы тривиально отдать картинку, нам совершенно нет нужды производить какие-то умопомрачительные вычисления. Как правило, выдачей статического контента занимается отдельный (в большинстве случаев штатный) сервлет, которому совсем не обязательно участвовать в общей сериализации. Более того, если поставить контейнер за Апачем (или другим веб-сервером), то можно сделать так, что запросы на получение статических ресурсов вообще не будут доходить до контейнера.
• Предположим, какая-то часть подгружаемых ресурсов таки действительно генерируется на лету. Например, индивидуализированная "шкурка" (skin) или картинка для CAPTCHA. Поскольку каждый ресурс загружается своим отдельным  GET-запросом, то обслуживание этих запросов на стороне сервера осуществляется в порядке общей очереди. То есть: заявы типа "я от Иван Иваныча" (в смысле, от ранее загруженной страницы), тут не прокатывают. Поэтому страшилка "остальные юзеры и вовсе лапу сосут пока первый высасывает данные" для меня означает одно из двух: либо товарисч не совсем понимает, о чем говорит, либо умышленно искажает факты (любопытно, с какой целью?).
• Ну и до кучи про медленные соединения. "При не очень-то быстрой сети такие задержки добавляют дискомфорт пользователю". При не очень-то быстрой сети дискомфорт определенно наблюдается, но вот какое это отношение имеет к вопросу о сериализации? Прошу обратить внимание, я нигде не говорил, что сериализованная обработка означает долгая обработка. Скорее наоборот, и мы к этому еще вернемся.
  
  К слову, в распоряжении веб-разработчика имеется масса возможностей сделать жизнь пользователя с тонким коннектом по возможности более приятной: компактная верстка, грамотные заголовки кэширования статических ресурсов на стороне клиента, сжатие контента перед отправкой - все это можно и нужно задействовать, но это уже несколько другая тема.

Идем дальше. Что там у нас по списку?



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

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



Не к чести оппонента, мы опять наблюаем здесь литературный прием под названием подмена понятий. Крутое оборудование - это только лишь много процессоров? А как насчет тактовой частоты, большой памяти, хорошего кэша второго уровня, быстрой дисковой подсистемы, сегментирования базы по множественным дискам? Я уж не говорю о выделении отдельных серверов под СУБД, сервер приложения, веб-сервер и т. д.



Ага, так вот, значит, к чему все это! Значит, когда сервер начнет задыхаться под нагрузкой, мы ему - раз - втыкнем 24 дополнительных процессора, и все опять станет хорошо. Вот ведь как замечательно! А теперь расказываю, как все обстоит на самом деле, ибо это и есть самое интересное.

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

Радости эти примерно такого рода: взаимные блокировки, фантомные чтения, устаревание данных в памяти, и т. д., и т. п. Тут можно попытаться сделать вид, будто база сама разрулит все конфликты (да, в Oracle и Postgres есть очень ловкая штука - многоверсионность по чтению, которая подчас здорово помогает). Ан фигушки. Дело вот в чем.

В любом серьезном приложении в памяти околачивается немалое количество объектов, имеющих датабазное происхождение. То есть: даже если в нем не используется явный программный кэш-менеджер типа Tangosol Coherence, такие объекты - суть программное представление неких датабазных данных. Они могут болтаться в сессиях, в контексте сервлета, в синглтонах - где угодно. При этом их надо каким-то образом держать в согласованном состоянии с подлежащей (underlying) базой: своевременно обновлять, удалять и пр. Это порождает одну маленькую проблему.

Поскольку потоков у нас теоретически больше одного, то методы, изменяющие состояние этих объектов, должны быть в обязательном порядке синхронизированы. Если мы с этой целью тупо объявим их все в виде public synchronized void setParameter(int parameter), то я могу нас сразу поздравить: мы разом получим источник непреходящей острой головной боли на многие годы вперед.

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

Поэтому. Недостаточно просто объявить все методы synchronised. Надо иметь хоть какую-то вменяемую стратегию: что, когда и посредством чего блокировать. Чтобы это стало возможным, необходимо наличие как минимум трех условий:

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

Правда жизни, однако, заключается в том, что специалистов, обладающих названными качествами, во всем мире - ну очень немного. Намного меньше, чем проектов, где это требуется. По очень прозаической причине: в силу действия расширенного закона Стёрджена (Sturgeon's Law).

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

Если коротко: полная синхронизация оправдывает себя при выполнении двух условий:

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

Обращаю особое внимание на второй пункт, ибо в нем заложен ключ к оценке масштабируемости подхода. Если мы добъемся такой производительности, что запрос будет отрабатывать за, скажем, 50 ms, то будем все еще вполне комфортно чувствовать себя даже на нагрузках порядка 10 обращений в секунду. А это, повторяю, такая нагрузка, которой далеко не каждое приложение может похвастать. Сверх этого порога - это уже совсем другая категория приложений, другие архитектуры и пр. И другая ценовая категория, само собой.

Все, на этом у меня все.

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

Я бы не стал так подробно распинаться, памятуя кое-какие библейские заветы, но тут вот какое дело. Мы с вами находимся на форуме, материалы которого читали, читают и будут читать в веках. У меня здесь есть репутация, которая складывалась не один день и которой я дорожу. И когда приходит какой-то гусь с бугра и сходу делает заявления о моей профнепригодности и позволяет себе хамские, назовем вещи своими именами, реплики в мой адрес, то дать такому гражданину адекватный ответ - это для меня вопрос чести и достоинства.

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

Безо всяких смайлов.

Stampede, 
Я не собираюсь тратить на ваши глупости 6 часов, по этому скажу кратко о том, в чём я с вами согласен, а именно:

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

Вот абсолютно с вами в этом согласен по части применения в системах массового обслуживания 


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

PS
Ответными оскорблениями я вас осыпать не стану поскольку у меня нет нужды поддерживать видимость собственной авторитетности ;)

Внимательно перечитал обсуждение. И даже несколько раз. Но вопросы остались...

1) Сериализация запросов и обработка юзверей по очереди. Но разве сериализация - это не способ сохранения объекта в независимом от конкретного приложения состоянии? То есть подход, когда класс имплементит интерфейс java.io.Serializable (или java.io.Externalizable), и может быть сохранён вне программы. Каким образом это связано с входящей очередью пользователей?

2) Как сохранять пользователезависимые значения в JSP/сервлете? Прятать всё в сессию? Писать в кукисы? Каждый раз вызывать

если необходимо сравнить сохранённое значение с константой? Имхо изврат... Есть более человеческие способы работы с уникальными пользователю значениями?

Shaggie

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

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