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/singletons/
[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/default_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]
