Почему бросок EJBException является “рекомендуемой” практикой?
Вы не можете сделать этого программно (безопасным способом, который является), не составляя новую таблицу.
то, Что делает Руководитель предприятия, когда Вы фиксируете переупорядочение, должно составить новую таблицу, переместить данные и затем удалить старую таблицу и переименовать новую таблицу к существующему имени.
, Если Вы хотите свои столбцы в особом порядке/группировке, не изменяя их физический порядок, можно создать представление, которое может быть тем, чего Вы требуете.
3 ответа
Создание исключения EJBException рекомендовано спецификацией EJB (14.2.2 в EJB 3) в тех случаях, когда EJB не может восстановиться после исключения он встречает. В спецификации также говорится, что EJB может разумно разрешить (не отмеченным) системным исключениям распространяться в контейнер.
Я согласен с вашим чтением спецификации, что в таких случаях методы обратного вызова жизненного цикла не будут вызываться контейнером, и следовательно, вы беспокоитесь о том, что любая очистка ресурсов, которая обычно происходит в обратном вызове ejbRemove () , не произойдет, и поэтому существует опасность утечки ресурсов.
Мой опыт показывает, что возникает очень много сложных проблем, потому что отсутствия защитного кодирования. «Ситуация X не может возникнуть в хорошо управляемой системе, и если это произойдет, то вся система сломается, поэтому я»
ejbRemove , вы можете разрешить распространение SystemExceptions - но я не уверен, что это удобно. Вы зависите от библиотеки, и она генерирует исключение NullPointerException . Is на самом деле более надежен для перехвата и повторного выброса TransientException ? EJBException или системного исключения, чтобы экземпляр был уничтожен, но, по крайней мере, вы пытались выполнить уборку. То, происходит ли утечка ресурсов, зависит от того, как эти ресурсы администрируются. Отброшенный компонент получает сборщик мусора, отказываясь от своей ссылки на ресурс, который, в свою очередь, собирает мусор, когда на него больше нет ссылок. Если ресурс также хранится в коллекции с путем к корневому каталогу, утечка будет происходить, если в контейнере нет диспетчера пула, который может обнаруживать простаивающие ресурсы и перерабатывать их.
Я согласен с вами, что компонент должен обрабатывать любые исключения, которые он может сам по себе и пусть результат будет известен вызывающему. Для меня антипаттерн в описанной вами ситуации - это использование исключений для передачи состояния объекта. Исключения должны быть исключениями, а не использоваться как возвращаемые значения.
Контейнер все еще может зафиксировать текущую транзакцию, даже если метод EJB вызвало исключение приложения. Если ваш метод EJB может вызвать исключение приложения, вам следует рассмотреть возможность использования EJBContext.setRollbackOnly () следующим образом:
public void method() throws ApplicationException {
try {
...
} catch (ApplicationException e) {
_context.setRollbackOnly();
throw e;
}
}
Создание исключения EJBException или системного (не отмеченного) исключения означает, что контейнер автоматически откатит транзакцию. См .: http://java.sun.com/j2ee/tutorial/1_3-fcs/doc/Transaction3.html
Если компоненты EJB вашей системы не перехватывают и не обрабатывают исключения приложений, то код, который их генерирует, может в частично завершенной операции с фиксацией своих изменений.
Это может привести к трудно обнаруживаемым ошибкам, поскольку «пользовательский миф» о методе EJB с CMP состоит в том, что он отображается на транзакцию, которая является атомарной. Частично полная бизнес-логика атомарно передается в базу данных. На практике это очень сбивает с толку. В статье Джоэла о дырявых абстракциях: http://www.joelonsoftware.com/articles/LeakyAbstractions.html объясняется, почему.
Если в вашей системе есть EJB-компоненты, которые неправильно обрабатывают исключения приложений, логичный ответ - исправить их, чтобы они работали. Пока проблема не будет устранена, у вашей команды может быть разумная причина не желать, чтобы исключения приложения выдавались из EJB-компонентов.