Bom pessoal, peguei o bonde andando mas vou tentar acompanhar :)
Vou fazer coloca��es apenas naquilo que o pessoal n�o discutiu muito, e apenas
para
reiterar algumas posi��es.
j2ee wrote:
>
> * Sobre as transa��es
> ---------------------
>
> [Sven]
>
> J2EE � um plataforma transacional, performance n�o � da primeira
> importancia.
>
> Pois �. Com um app server bom, vc pode setar um flag que somente os EJB
> acessam os dados. No J2EE RI isso n�o funciona, portanto, poderia utilizar
> um flag (boolean isDirty) que indica q vc alterou algo.
>
> Fora isso, usa Value Object Design Pattern e coloque 2 metodos no EJB,
> getData e setData.
>
>
> [Zanata] - Nova pergunta
>
> Uma das respostas pediu para que eu desativasse a transa��o do m�todo, mas
> no CMP eu tenho apenas 03 alternativas para transa��es: Required, Require
> New, Mandatory. No BMP sim eu tenho 05 alternativas: Suportada, Requerida,
> Requer Nova, Mandat�ria e N�o requerida. Isso est� correto ou acontece
> apenas no servidor de refer�ncia?
Os AppServers do mercado suportam o conceito de cache e pool (JBoss, Weblogic,
Orion,
etc.). O cache realizado somente no AppServer (de acordo com pol�tica espec�fica do
AppServer) pode ser entre as transa��es ou que o Container possue acesso exclusivo ao
BD, tomando para si a maneira como realizar a sincroniza��o com o BD. O Cache faz com
que um update/insert/delete n�o seja realizado imediatamente no BD (exclusivuidade de
acesso do AppServer).
� muito importante considerar o tipo de commit usado pelo AppServer e se �
configur�vel ou n�o (espec. 10.5.9), o n�vel de isolamento da transa��o n�o �
responsabilidade requerida do Container, � opcional (espec. 17.3.2) pode ser definida
na configura��o do DataSource (JBoss suporta isso).
Alguns AppServers suportam o conceito de EntityBean read-only, o que j� causa
um ganho
de performance consider�vel.
O CMP 2.0 suporta apenas os tipos de transa��es (Required, RequiresNew,
Mandatory,
etc.), mas o container pode suportar (opcionalmente, mas n�o port�vel) os tipos
"NotSupported, Supports", quando o DataSource n�o suportar transa��es, mas isso �
dif�cil acontecer. (17.4.1). Sobre o BMP suportar todos os tipos de transa��es, o
container assume que a persist�ncia � feita por motivos que o CMP n�o suporta (BD n�o
SQL, n�o transacional e coisas assim) ent�o pode-se colocar qualquer atributo
transacional.
>
>
>
> * Banco de Dados Compartilhado entre Container X Sistemas Legados
> ------------------------------------------------------------------
>
> � poss�vel compartilhar um Banco de Dados que est� sendo utilizado para
> persist�ncia de entidades atrav�s de um EJB Container com outras
> aplica��es/sistemas externos?
>
> Se for poss�vel, quais os cuidados a serem tomados?
Explicado um pouco anteriormente, o Recurso (BD, LDAP, etc.) pode ser
compartilhado,
s� tomando-se o cuidado de que o cache seja configurado adequadamente no AppServer, o
tipo de commit, o isolamento da transa��o e o tipo de lock Pessimista/Otimista (ufa).
Em ambientes com muitos updates no BD, e que o BD compartilhado � melhor que o tipo
de lock seja Pessimista para garantir a integridade de dados.
>
>
>
> * Servidor de Aplica��es
> ------------------------------------------------------------------
>
> [Sven]
>
> De acordo com o Sven, o WebLogic 7 � o melhor servidor comercial. J�
> t�nhamos feito um levantamento e ele est� em 1o. lugar nas pesquinas.
>
> Websphere � uma crian�a problem�tica. Apesar que n�o tem CMP EJB 2.0
> precisa de um DB2 ou Informix para passiva��o de EJB etc. �
> /extremamente complicado a instala��o � complicado o deployment de
> aplica��es. Ele n�o � um produto mas uma combina��o de v�rias produtos.
> Prefiro ficar sem clientes do que mexer com cliente com websphere. (OK,
> Tomarei cuidado)
>
> J� utilizei Weblogic, Oracle, Websphere e Orion e Borland. Destes Weblogic
> d� o menos dor de cabe�a.
>
>
> [J�lio Cesar - CESAR]
>
> De acordo com o C�sar, o JBoss � um bom servidor de aplica��o, e realmente,
> de acordo com que verifiquei ele est� em 4o lugar nas pesquisas. Por ser um
> servidor n�o-comercial, acho que esta � uma boa ferramenta.
>
> Verifiquei que o �nico problema dele n�o ter o "selo" J2EE (se � assim que
> se fala...) � que para isso o fornecedor do servidor precisa pagar para a
> Sun algo em torno de US$20000.
>
> Por ser uma ferramenta n�o-comercial, quem � que vai pagar a conta?! :)
>
> Do pouco que vi, achei o servidor muito bom. Mas n�o avancei muito devido
> ao monte de d�vidas que apareceram e resolvi "despejar" todas elas na lista.
Tenho estudado/trabalhado com o JBoss e ele anda "em dia" com as
especifica��es, sendo
o 1o a implementar JMX como objetos de infra-estrutura, j� tem boa parte a
implementa��o do JSR 77 (J2EE Management Specification), e possue muitas
configura��es de CMP (read-only, pool, cache, jboss-ql - muito boa -, read-ahead em
finders/selects), suporta cluster, toler�ncia a falhas, deployment em apenas 1
m�quina vai para o cluster inteiro, etc.
O que acho muito bom no JBoss � a caracter�stica de MicroKernel dele, em que
tudo s�o
servi�os: DataSources, Persist�ncia, JMS, Conectores, Adaptadores, Cluster, Farming,
etc. Possibilitando que seja feita uma customiza��o incr�vel.
Foi dito (n�o me lembro em qual email) que para escrever uma aplica��o para o
JBoss
seria necess�rio escrever os deployment descriptors e tal. Digo que n�o � necess�rio,
pois o JBoss vem com pr�-configura��es que fazem com que uma aplica��o EJB seja
realizado o deployment somente com o ejb-jar.xml (requerido da espec.). Claro que nos
casos dos entities os nomes dos atributos da tabela ser�o iguais do bean, e outras
configura��es default.
O JBoss est� pronto para instalar e rodar.
[]s
Claudio Miranda
---------------------------------------------------------------------
Para cancelar a subscri��o, envie mensagem para:
[EMAIL PROTECTED]
Para comandos adicionais, envie mensagem para: [EMAIL PROTECTED]
