Spock,
Valeu pela sua bela resposta !
Hei de consultar o link ao qual mencionaste para procurar saber mais
� respeito de minhas indaga��es e d�vidas qto � performance.
Grato !
Abra�[]s,
Max Ricardo Mercurio Ribeiro
IT & Business Consultant for Alcoa Company
e-mail: [EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]> (company)
/ [EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]> (personal)
phones # : (0x11) 9101-5511 mob. / (0x11) 3741-4418 com.
-----Original Message-----
From: Dr. Spock [mailto:[EMAIL PROTECTED]]
Sent: Monday, 6 de January de 2003 11:52 PM
To: [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Subject: Re: [enterprise-list] DUVIDA : Pool de Conexoes
Caro Max,
Tenha um certo cuidado com o pattern 'Singleton'. Este ter� uma �nica
inst�ncia de pool se todas as suas aplica��es rodarem na mesma inst�ncia
de JVM. Contudo, isso tamb�m n�o � necessariamente verdade quando
estamos falando de um servidor de aplica��es. As v�rias aplica��es que
residem num servidor de aplica��es J2EE tem, pode defini��o da
especifica��o, que manter um isolamento entre os v�rios objetos de uma
aplica��o com os v�rios objetos das outras aplica��es. Estas regras de
isolamento tendem a se tornarem cada vez mais importantes (Veja a
proposta em andamento no JCP - http://www.jcp.org/ - atrav�s do JSR 121,
refer�ncia [1]).
Cada inst�ncia de JVM passa a ter a sua inst�ncia de pool e cada
aplica��o isolada no servidor de aplica��es passa a ter a sua inst�ncia
de Pool. Para obter um pouco mais de detalhes veja a refer�ncia [2].
Ent�o, naturalmente estamos sujeitos a ter v�rias inst�ncias de pool
(semelhante ao 'cen�rio atual' apresentado por vc) num ambiente
distribu�do e/ou baseado em servidores de aplica��es J2EE (no mundo Java
junto com o mundo corporativo n�o teremos como escapar do J2EE, esquece
o Not Yet! :)).
Contudo, uma solu��o j� existe e � aplicada em v�rios servidores de
aplica��es J2EE disponiveis no mercado: O recurso, ou melhor, o servi�o
de 'pool' � um recurso oferecido pelo servidor de aplica��es (via
'container'), como parte do mesmo, para as aplica��es. J� vemos
normalmente um 'pool' sendo administrado pelo 'container' e
compartilhando os objetos com as v�rias aplica��es (semelhante ao
'cen�rio 1' apresentado por vc). Mas, para tudo funcionar em harmonia,
dada as necessidades especificas de uma aplica��o, os seus arquivos
descritores podem conter informa��es sobre os objetos a serem criados no
'pool' (ex.: podemos necessitar de conex�es especificas de banco de
dados usadas somente pela aplica��o - e se as v�rias aplica��es utilizam
o mesmo banco ao definir as mesmas configura��es espec�ficas nos
descritores? Da� vem o pool centralizado no 'container', otimiza��o!).
Toda a explana��o anterior n�o responde completamente �s suas
indaga��es. Alguns aspectos de performace, de quando usar ou n�o
'pools', da quantidade limite de objetos gerenciados pelo 'pool', etc,
podem ser obtidos em alguns artigos dispon�veis na rede. Veja as
refer�ncias [3], [4], [5] e [6], por exemplo. Em especial, nas
refer�ncias [3] e [4] podemos verificar que realizar 'pooling' tem o
prop�sito b�sico de utilizar os recursos que temos dispon�veis da melhor
maneira poss�vel. Por exemplo, imagine v�rias aplica��es que realizam
transa��es em banco de dados com per�odos de tempo muito breves. Uma
aplica��o precisa de uma conex�o com o banco de dados para realizar a
sua transa��o por um per�odo de tempo muito curto. Para que serviria
esta mesma conex�o, j� estabelecida, na maior parte do seu tempo de
vida? Seria interessante reutiliz�-la em outras transa��es da mesma ou
de outras aplica��es. Da� o 'pool' se torna a ferramenta para tal
reutiliza��o e gerencimento desta reutiliza��o. O mesmo � v�lido para
'threads' e at� mesmo para conex�es de rede (curiosidade: a rela��o de
usu�rios por linha telef�nica nos ISPs funcionam devido o mesmo
principio e na rela��o de assinantes e tamanho da rede de telef�nia).
Sabemos que estes recursos s�o custosos para inicializa��o e destrui��o
(garbage collection? tb!). Portanto, a melhor utiliza��o e otimiza��o
destes recursos tornar-se-� necess�rio e fundamental para uma aplica��o
que necessita de performace e escalabilidade (e redu��o de custos no
exemplo curioso).
Contudo, quanto mais objetos s�o gerenciados pelo 'pool' mais custoso
se torna este gerenciamento. Sabemos que � necess�rio 'threads' que
administram e monitoram os objetos contidos no 'pool'. Ent�o, quanto
mais objetos gerenciados menor ser� a performance neste gerenciamento. E
os poss�veis aspectos de 'thread syncronization' se tornam relevantes
frente ao volume cada vez maior de objetos administrados e de aplica��es
cliente que s�o usu�rios deste 'pool'. Usu�rios de uma �nica inst�ncia
('singleton') do 'pool'! Num ambiente de v�rias 'threads'
(clientes/usu�rios) o gerenciamento do 'pool' deve garantir o
sincronismo para o seu acesso e para a sua utiliza��o. Gargalos de
performace? Acho que agora estou come�ando a responder �s suas
indaga��es ...
Walter Kriha, autor da refer�ncia [7], escreve: "We pool things
because we want to save either time - if it takes a lot of time to build
an object - or memory - if an object has a large footprint."
Espero ter contribuido ... A partir de agora vc tem em m�os algumas
refer�ncias que podem com�ar lhe ajudar a responder a maior parte das
suas indaga��es. Quem sabe?
Valeu ... []�s
Spock
--------------------------------------------------------------------
[1]. Application Isolation API Specification
http://www.jcp.org/en/jsr/detail?id=121
[2]. When is a Singleton Not a Singleton?
http://developer.java.sun.com/developer/technicalArticles/Programming/single
tons/
[3]. What is the best method of pooling objects?
http://developer.java.sun.com/developer/qow/archive/138/index.jsp
[4]. Make Object Pooling Simple
http://www.fawcette.com/javapro/2002_11/online/obj_krangaraju_11_08_02/defau
lt_pf.asp
[5]. Build your own ObjectPool in Java to boost app speed
http://www.javaworld.com/javaworld/jw-06-1998/jw-06-object-pool_p.html
[6]. Best Practices in Pooling
http://otn.oracle.com/products/ias/pdf/pools-best-practices.pdf
[7]. Pooling: why, what and how much?
http://www.kriha.de/krihaorg/docs/papers/portalchunked/ch05s32.html#d0e1730
----------------------------------------------------------------------
Ribeiro, Max R. M. wrote:
> Galera,
>
> Estou com uma d�vida um tanto que ingrata.
>
> Tenho um pool de conex�es do estilo (SINGLETON), ou seja 1
> inst�ncia apenas.
> Hoje esta � especifica para 1 (uma) aplica��o apenas ! Ex:
>
> Cen�rio Atual
> -------------
> classe DBPool
> |
> +---- Connection (applic A) *usando
> |
> +---- Connection (applic A) *usando
> |
> +---- Connection (applic A) *livre
>
>
>
>
> No entanto, penso em utilizar esse pool para novas aplica��es
> tamb�m ...
>
> Minha d�vida � :
> - algu�m por acaso sabe se a JVM aguentar� in�meras conex�es
> com
> o BD de in�meras aplica��es sem quaisquer problemas de performance ? Ex :
>
> Cen�rio Proposto 1
> ------------------
> classe DBPool
> |
> +---- Connection (applic A) *usando
> |
> +---- Connection (applic A) *usando
> |
> +---- Connection (applic A) *livre
> |
> +---- Connection (applic B) *usando
> |
> +---- Connection (applic B) *livre
> |
> +---- Connection (applic C) *livre
> |
> +---- Connection (applic C) *livre
> |
> +---- Connection (applic D) *usando
>
>
> - ou seria mais adequado eu criar uma nova inst�ncia desse
> pool
> de conex�es espec�fico para cada aplica��o que irei utilizar ?
>
> Cen�rio Atual
> -------------
> classe DBPoolA
> |
> +---- Connection (applic A) *usando
> |
> +---- Connection (applic A) *usando
> |
> +---- Connection (applic A) *livre
>
> classe DBPoolB
> |
> +---- Connection (applic B) *usando
> |
> +---- Connection (applic B) *livre
>
> classe DBPoolC
> |
> +---- Connection (applic C) *usando
> |
> +---- Connection (applic C) *livre
>
> (assim em diante)
>
>
> PS - Esse pool que tenho J� CONTROLA conexoes minimas, extras
> e
> tempo de conex�o ociosa
>
>
> Penso dessa maneira, pois acredito que poderia estar
> sobrecarregando um �nico pool j� que estou falando de pelo menos 50
> aplica��es distintas (preocupa��es qto � performance).
>
> Por�m, claro, posso estar enganado qto � isso !
>
>
>
>
> Agrade�o futuros coment�rios e quaisquer viv�ncias nesse
> sentido !
>
>
>
> Abra�[]s,
>
> Max Ricardo Mercurio Ribeiro
> IT & Business Consultant for Alcoa Company
>
> e-mail:_ [EMAIL PROTECTED]
> <____mailto:[EMAIL PROTECTED]>_ (company) /_
> [EMAIL PROTECTED] <____mailto:[EMAIL PROTECTED]>_
(personal)
>
> phones # : (0x11) 9101-5511 mob. / (0x11) 3741-4418 com.
>
---------------------------------------------------------------------
Para cancelar a subscri��o, envie mensagem para:
[EMAIL PROTECTED]
Para comandos adicionais, envie mensagem para:
[EMAIL PROTECTED]
---------------------------------------------------------------------
Para cancelar a subscri��o, envie mensagem para:
[EMAIL PROTECTED]
Para comandos adicionais, envie mensagem para: [EMAIL PROTECTED]
