Quando eu entrevisto algu\u00e9m pra uma vaga de emprego, eu sempre pergunto se podemos utilizar threads em escopo JEE. J\u00e1 recebi v\u00e1rias, resposta, algumas preocupantes, outras espertas. Resolvi fazer um post para esclarecer essa quest\u00e3o.<\/p>\n
A pr\u00f3pria documenta\u00e7\u00e3o da Oracle<\/a> deixa claro que a fun\u00e7\u00e3o do gerenciamento de threads \u00e9 do pr\u00f3prio container. A especifica\u00e7\u00e3o<\/a> diz que \u00e9 proibido o uso de threads.<\/p>\n The enterprise bean must not attempt to manage threads. The enterprise bean must not attempt to start, stop, suspend, or resume a thread, or to change a thread\u2019s priority or name. The enterprise bean must not attempt to manage thread groups.<\/p><\/blockquote>\n Permitir que a aplica\u00e7\u00e3o fa\u00e7a o controle de threads ir\u00e1 interferir no controle do ciclo de vida dos componentes do container. Ent\u00e3o estamos proibidos de usar threads diretamente na aplica\u00e7\u00e3o (elas existem, mas controladas pelo container). O uso direto delas implicaria na viola\u00e7\u00e3o e perda dos recursos fornecidos pelo container: seguran\u00e7a, clustering, controle de transa\u00e7\u00e3o e afins.<\/p>\n Mesmo o controle sendo feito no container, podemos utilizar as vantagens que as threads oferecem sem comprometer a integridade do container. Na maioria dos casos, conhecer os componentes poss\u00edveis da arquitetura \u00e9 suficiente para n\u00e3o utilizar threads diretamente. Por exemplo, um envio de e-mail em lote pode ser desenvolvido com uma fila JMS em conjunto com um MDB. Um agendamento, pode ser feito utilizando Quartz ou um Timer Service.<\/p>\n Al\u00e9m das threads, se voc\u00ea leu as refer\u00eancias acima, ir\u00e1 ver que n\u00e3o podemos nem gravar arquivos dentro do container, pois voc\u00ea perderia o controle da concorr\u00eancia, em ambientes clusterizados voc\u00ea teria problemas com arquivos que n\u00e3o s\u00e3o distribu\u00eddos em v\u00e1rias m\u00e1quinas, opera\u00e7\u00f5es com arquivos tamb\u00e9m n\u00e3o s\u00e3o transacionais e teria problemas com seguran\u00e7a. Caso deseja realmente fazer isso, voc\u00ea ter\u00e1 que desenvolver esse controle manualmente, como um sistema de arquivo distribuido entre os n\u00f3s do cluster, controle de transa\u00e7\u00e3o manual como um arquivo de lock, um controle de concorr\u00eancia para garantir que um arquivo seja lido ou escrito por vez, eliminando a concorr\u00eancia entre os clusters e um mecanismo de detec\u00e7\u00e3o ou compensa\u00e7\u00e3o de erro ou rollback em caso de falhas entre as opera\u00e7\u00f5es utilizando arquivos. O que n\u00e3o \u00e9 uma tarefa f\u00e1cil, mas \u00e0s vezes se faz necess\u00e1rio.<\/p>\n H\u00e1 casos espec\u00edficos que existe a necessidade de uso threads, mas devemos fazer isso sem comprometer o container, para isso h\u00e1 solu\u00e7\u00f5es como a JSR 236<\/a>, que \u00e9 a api de utilit\u00e1rios de concorr\u00eancia (vulgo, usar thread do jeito certo) e se tornou padr\u00e3o na especifica\u00e7\u00e3o do JEE 7. H\u00e1 uma boa refer\u00eancia do uso aqui<\/a> e aqui<\/a>.<\/p>\n Resumindo: Evite o uso de threads em escopo JEE, caso voc\u00ea identifique a necessidade, verifique se algum componente padr\u00e3o resolve o seu problema, caso contr\u00e1rio, utilze APIs adequadas para usar threads sem comprometer os recursos fornecidos pelo JEE.