Java bean - synchronized method - кто тут прав?

[Sabina]

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

Какой монитор вы имеете в виду?
JSP - на сервере, FormUtil, методы которого она вызывает тоже на сервере.

Сабина

[Chelya]

Sabina,

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

2. synchronized в данном классе не нужен, так как доступ в PageContext и HttpSession не надо синхронизировать.

3. Данный класс является наглядным примером того как не надо писать программы. Начиная с того, что JSP не должно иметь business logic и заканчивая тем, что static functions в большинстве случаев - зло. Static functions "break" OOP design (like global variables), делает maintanance сложнее, extensibility хуже.

[Sabina]

3. Данный класс является наглядным примером того как не надо писать программы. Начиная с того, что JSP не должно иметь business logic и заканчивая тем...

То есть вызов FormUtil из JSP можно назвать "JSP имеет business logic"?
А где обычно храниться business logic? В данный момент FormUtil входит в состав WEB-INF/lib/...beans.jar

[Amayan]

...static functions в большинстве случаев - зло. Static functions "break" OOP design (like global variables), делает maintanance сложнее, extensibility хуже.

Пожалуйста, объясните подробнее, почему Вы считаете, что static methods в большинстве случаев зло. По возможности аппелируя к личному опыту, а не к книгам, которые Вы прочитали про паттерны в Java или J2EE. Для меня будет весьма ценно, если вы сможете подкрепить утверждения "maintanance сложнее, extensibility хуже" описаниями конкретных проблем, с которыми Вам довелось столкнутся.
Я это все спрашиваю не из-за того, что собираюсь "зацепить" Вас. Я сравнительно недавно занимаюсь Java, но у меня уже сложилось впечатление, что большинство Java-программистов необоснованно избегают static methods, хотя стандартная библиотека Java использует их вовсю. Как например и Jakarta Commons.

[Dedal]

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

EJB != J2EE

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

да, synchronized для того, чтобы поставить методы в очередь (сериализовать).

На самом деле синхронизация здесь вообще не нужна т.к. вы в данном случае не работаете с переменными обьекта FormUtil.

Так в чем же тогда суть синхронизации? Как факт того, что метод может вызываться только одним тредом at a time соотноситься с тем, работаю я или не работаю с переменными объекта Form Util?Сабина

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

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

Какой монитор вы имеете в виду?
JSP - на сервере, FormUtil, методы которого она вызывает тоже на сервере.

Сабина

Монитор объекта, который Вы пытаетесь блокировать с помощью synchronized. Вам нужно почитать про потоки и ознакомиться хотя бы с базовыми принципами и терминологией. Монитор к классу тоже прилагается, разумеется. Хотя я не знаю, как static synchronized будет работать в случае нескольких класслоадеров. Надо почитать...

2. synchronized в данном классе не нужен, так как доступ в PageContext и HttpSession не надо синхронизировать.

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

3. Данный класс является наглядным примером того как не надо писать программы. Начиная с того, что JSP не должно иметь business logic и заканчивая тем, что static functions в большинстве случаев - зло. Static functions "break" OOP design (like global variables), делает maintanance сложнее, extensibility хуже.

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

[testuser]

Что значит static методы это зло? Их просто нужно применять в тех случаях, когда их нужно применять.
Если метод не зависит от конкретного экземпляра класса (объекта), тогда его нужно делать static. Делать их не статическими просто не имеет смысла, так как нужно будет создать объект только для того чтобы произвести какое-то действие, свойственное классу.
К примеру в классе Integer есть статический метод parceInt(String s). Было бы глупо создавать новый объект только для того, чтобы пропарсить строку - для таких целей есть статические методы.

[JustMax]

EJB != J2EE

. При чем тут EJB ? Вы давно спецификацию J2EE перечитывали ? A также спецификации всех технологий входящих в J2EE и общие принципы на которых они базируются ?

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

Одно маленькое уточнение - ето никак не поможет при попытке изменения обьекта, ссылка на который передается как параметер в synchronized метод. Он с такой же легкостью будет изменен в то же самое время методами других классов&потоков.
Единственное спасение - synchronized методы, или если ето чужой или final класс, обеспечить изменения такого обьекта исключительно через унаследованный класс или класс wrapper, но уже с synchronized методами.

[vlad12345]

Насколько я помню JSP/Servlets спецификацию, конкретный pageContext объект может быть доступен только одному thread-у (по окончании thread-а может быть reused, но параллельный доступ исключен), так что синхронизация в данном случае ни к чему.

В принципе такой вот FormUnit в теории мог бы иметь смысл, если бы предполагалось через него также обращаться и к session, application объектам и другим, действительно требующим синхронизации. Только тогда ВСЕ обращения должны делаться ТОЛЬКО через FormUnit методы (светофоры были бы бесполезны если бы не все водители соблюдали правила) -- этакий распорядитель строго следящий за очередью. Вот только скорее всего это оказалось бы узким местом в аппликации, представьте, скажем, что в зале работает десять касс, но распорядитель следит , чтобы в зале мог находиться только один человек, а остальные ждут в очереди за дверью.

Еще мне кажется, что на FormUnit как-то слишком много всего возложено, например при запросе getAction заодно может сработать logoff - session.invalidate(), когда-нибудь такой побочный эффект может оказатья неприятной неожиданностью. И все эти synchronized и final скорее всего были сделаны для универсализма и единообразия. Кстати final могло бы пригодиться, если бы внутри методов применялись inner classes, работющие с параметрами метода, т.е. из соображений универсальности -- пусть все будет final, где-нибудь пригодится ...

[vlad12345]

2. synchronized в данном классе не нужен, так как доступ в PageContext и HttpSession не надо синхронизировать.

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

Imho, с Session действительно надо поосторожнее: пользователь может открыть в броузере несколько окон, или еще проще -- несколько фреймов.

[vlad12345]

del... sorry, не в тему

[Palych]

Во-первых, согласно Вашему описанию, FormUtils не попадает под определение JavaBean.

Это один из классов входящих в состав универсального jar, которым мы пользуемся в классе. Препод его называет ...beans.jar Там всякие SQLUtils, GifEnсoder, класс для отправки емейлов и проч. Все что нужно для небольшого JSP приложения, которое делает базовые вещи: user self-registration, login, password reminder,etc.

Stalo byt' eto utilities. Sudya po vsemu mnogie iz nih mogut byt' zameneny na Beans.

Во-вторых, использование статических методов видится мне мягко говоря странным. JSP позволяет определить scope of the bean декларативно, а вы возлагаете это на сам класс... Проще говоря - методы не должны быть на static ни synchronized.
.

А как например декларативно?
В самом JSP обращение выглядит примерно так:

Code: Select all

String action = FormUtil.getAction(pageContext);
String sr_username = FormUtil.getValue(SR_USERNAME, pageContext);
String sr_password = FormUtil.getValue(SR_PASSWORD, pageContext);...

Как можно декларативно определить scope of the bean? Заранее прошу прощения если вопрос тупой, но все мы когда-то учимся.
Если долго объяснять, буду признательна хотя бы за линк.

Code: Select all

<jsp:useBean id="beanInstanceName" scope="session" class="package.class" />

Look for JSP Spec on java.sun.com

Izvinyayus' chto ne mogu podrobney - chto-to s pal'cAmi - bolyat sobaki... Stareyu...

[Dedal]

EJB != J2EE

. При чем тут EJB ? Вы давно спецификацию J2EE перечитывали ? A также спецификации всех технологий входящих в J2EE и общие принципы на которых они базируются ?

При том, что только EJB постулирует однопоточную модель. Но EJB -- это только часть J2EE.

[Sabina]

Code: Select all

<jsp:useBean id="beanInstanceName" scope="session" class="package.class" />

Теперь понятно, то есть это если они будут заменены на beans. Пока же это в виде импорта в декларации <%@ page import="....beans.*"%> и мне как-то в голову не пришло на предмет тага useBean.
Да и проходили мы это в прошлом семестре

Сабина

[Chelya]

Навалились то все как
Конечно у static functions есть свои хорошие использования. Теперь по очереди:

То есть вызов FormUtil из JSP можно назвать "JSP имеет business logic"?

Вызов FormUtils из JSP не есть business logic. Business logic - это layer вашего application, который отвечает за конкретныю функциональность, а не за interfaces, например. Никакого хорошего определения в голову не лезет - уверен сейчас кто-нибудь напиишет лучше и понятнее. В нашем случае я бы сказал, что session.invalidate(); в getAction является частью business logic, tak kak it logs user out.

А где обычно храниться business logic? В данный момент FormUtil входит в состав WEB-INF/lib/...beans.jar

Business Logic - это концепт, а не что-то, что физически отличается от обычных классов.

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

Придумать можно много чего. В большинстве случаев архитектура будет неправильной. К тому же Sabinу это только запутает.

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

Нет ничего более постоянного, чем временный код. Нет такой маленькой плохо написанной программы, кототорая не переросла бы в большой headache. По крайбей мере из моего опыта.

Пожалуйста, объясните подробнее, почему Вы считаете, что static methods в большинстве случаев зло. По возможности аппелируя к личному опыту, а не к книгам, которые Вы прочитали про паттерны в Java или J2EE. Для меня будет весьма ценно, если вы сможете подкрепить утверждения "maintanance сложнее, extensibility хуже" описаниями конкретных проблем, с которыми Вам довелось столкнутся.
Я это все спрашиваю не из-за того, что собираюсь "зацепить" Вас. Я сравнительно недавно занимаюсь Java, но у меня уже сложилось впечатление, что большинство Java-программистов необоснованно избегают static methods, хотя стандартная библиотека Java использует их вовсю. Как например и Jakarta Commons.

Нащет Jakarta Commons не знаю - детально не приглядывался, но совневаюсь. Может какие-нибудь Common Utils. J2SE библиотечки тоже не ахти какой пример для подражания. Особенно то, что с первых версий идет.
Теперь о книгах. Всем кому интересна тема правильного программирования советую обзавестись "Expert One-on-One J2EE Design and Development" by Rod Johnson. На основе которой появился Spring Framework: http://www.springframework.org. Spring Framework на мой взгляд является эталоном дизайна.
Ну и наконец из собственного опыта. Static functions создают немало неудобств когда используются не по делу и не там, где надо. Кстати раньше по неопытности я совсем не обрашал внимания. Если static function можно избежать, то ее надо избежать. Если у вас много static functions, скорее всего это говорит о том, что что-то в дизайне неправильно.

[vlad12345]

Навалились то все как

А можно и мне тоже

Если static function можно избежать, то ее надо избежать.

А если нельзя? Например, можно ли избежать этого в классе Math?

Если у вас много static functions, скорее всего это говорит о том, что что-то в дизайне неправильно.

Согласен. Напрашивается аналогия с глобальными переменными в C++, их обилие явно дурной признак.

Static functions создают немало неудобств когда используются не по делу и не там, где надо.

Ну это утверждение будет верно применительно к чему угодно. Т.е. я к тому, что хотя надо быть осмотрительным со статическими функциями, но все-таки не такое уж зло. Иначе их вообще бы не было в java (как нету,например, goto, pointers и множественного наследования).