Как запустить фоновый процесс в Java EE
Для констант Enum - лучший выбор, ИМХО. Вот пример
открытый класс myClass {
public enum myEnum {
Option1("String1", 2),
Option2("String2", 2)
;
String str;
int i;
myEnum(String str1, int i1) { this.str = str1 ; this.i1 = i }
}
6 ответов
Java EE обычно пытается убрать многопоточность из опасений разработчиков. (Успех в этом - совсем другая тема).
JMS явно является предпочтительным подходом для решения этой проблемы.
С большинством параметров у вас есть возможность принудительной или имитации сериализации, даже если они не сериализуемы по умолчанию. В зависимости от данных можно обернуть их в сериализуемый объект, который может перезагружать данные. Это явно будет зависеть от параметра и приложения.
JMS - это способ Java EE для этого. Вы можете запускать свои собственные потоки, если контейнер позволяет вам, но это нарушает спецификацию Java EE (вы можете или не заботитесь об этом).
Если вас не заботит общая совместимость Java EE (если вы хотите фактически обращаются к потокам, а не к JMS), контейнер Oracle наверняка будет иметь собственные способы сделать это (например, Oracle Job Scheduler ).
Не знаю подробно OCJ4, но я использовал подход Thread и подход java.util.Timer для выполнения некоторых задач в приложении на основе Tomcat. В Java 5+ есть возможность использовать одну из служб Executor (Sheduled, Priority).
Я не знаю об onTimeout, но вы можете передавать параметры в самом сеансе, в контексте приложения или в статическом переменная (некоторые сказали бы, что не рекомендуется). Но название говорит мне, что он вызывается, когда время сеанса пользователя истекает, и вы хотите выполнить некоторую очистку.
Использование JMS - правильный способ сделать это, но он тяжелее.
Вы получаете преимущество в том, что если вам нужно несколько серверов, один сервер или что-то еще, когда серверы настроенная, ваша «Threading» теперь может быть распределена по нескольким машинам.
Это также означает, что вы не хотите отправлять сообщение для действительно тривиального объема работы или с большим объемом данных. Тщательно выберите точки интерфейса.
подробнее см. Здесь: stackoverflow.com/questions/533783/why-spawning-threads-in-j2ee-container-is-discouraged
Я без проблем создавал потоки в контейнере (Tomcat, JBoss), но они были действительно простые очереди, и я не полагаюсь на кластеризацию.
Однако EJB 3.1 представит асинхронный вызов, который может оказаться полезным: http://www.theserverside.com/tt/articles/article.tss?track=NL-461&ad=700869&l=EJB3-1Maturity&asrc=EM_NLN_6665442&uid=2882457
Java EE doesn't really forbid you to create your own threads, it's the EJB spec that says "unmanaged threads" arn't allowed. The reason is that these threads are unknown to the application server and therefore the container cannot manage things like security and transactions on these threads.
Nevertheless there are lots of frameworks out there that do create their own threads. For example Quartz, Axis and Spring. Changes are your already using one of these, so it's not that bad to create your own threads as long as you're aware of the consequences. That said I agree with the others that the use of JMS or JCA is preferred over manual thread creation.
By the way, OC4J allows you to create your own threads. However it doesn't allow JNDI lookups from these unmanaged threads. You can disable this restriction by specifying the -userThreads argument.