Cita:
Iniciado por stone_neo 
Mira GreenEyed te cuento algunas cosas:
Mi tarea es dar mantenimiento a un Sistema que no corre en un Servidor de Aplicaciones determinado, con decirte que en nuestras PC hacemos el desarrollo en el JDeveloper con BC4J como servidor, en nuestro ambiente de testing por cuestiones de Licencia usamos como Servidor de aplicaciones JBoss, ahora en el cliente su servidor de aplicaciones de su ambiente de producción usan el OAS, por lo que los ingenieros que diseñaron la aplicación optaron por que la misma aplicación controle el pool de conexiones.
Y no tiene nada de malo, nosotros mismos lo hacemos en muchos casos, ya que tenemos nuestro propio Pool de conexiones, que desarrollamos cuando no existian los DataSources ni nada parecido. Sin embargo, dada una pregunta general, pues la respuesta es general y "en general" si no tienes algo ya desarrollado o tienes un caso especial, pues lo normal es usar DataSources por que hacer un pool propio no es cosa de dos días. De todas formas, dado que DataSource es una interfaz y todos los servidores de aplicaciones tienen formas de definirlos, el que se pueda cambiar el servidor de aplicaciones no implica necesariamente no usar DataSources, simplemente a la hora del deploy hay que asegurarse que en todos los servidores esten definidos bajo el mismo nombre. Pero vamos, tampoco es imprescindible hacerlo así.
Cita:
Iniciado por stone_neo Con respecto a que 10 pool de conexiones es mucho, te cuento que algunas de nuestras transacciones son muy largas por ejemplo la aprobación de un expediente consta de hacer inserts y updates a por lo menos 8 tablas y la actualización de documentos en word que son guardados en base de datos, por lo que esa transacción es muy pesada(notese que un expediente puede tener una buena cantidad de documentos que tambien deben ser aprobadas). Ahora en tema de concurrencia el sistema cuenta con 8 módulos, de las cuales en un solo modulo se encuentra cerca de 15 usuarios que son encargados la revisión de expedientes, y cerca de 90 usuarios que son los encargados de realizar la importación de expedientes desde otro sistema a este. Como te imaginaras existe mucha concurrencia.
De la misma forma que antes, pregunta general = respuesta general
. Pero lo que explicas no tiene nada de malo y es un caso donde haran falta muchas conexiones. Yo he trabajado en aplicaciones con 3 pools de 90 conexiones cada una... y se usaban todas! Pero en la mayoría de aplicaciones que he desarrollado, 10 conexiones ya eran muchas. Todo depende del tipo de acceso a la BDD y lo que tengas que mantener las conexiones "retenidas" sin devolverlas al pool. Por ejemplo, yo tenia una aplicacion en marcha que servía a una poblacion de ~16.000 usuarios con un pool de 10-12 conexiones abiertas, por que las transacciones eran cortas y nos cuidabamos de liberarlas en seguida. Rehicieron el sistema y la misma aplicación ahora ha pasado a necesitar mas de 80, simplemente por la forma de hacerla.
Si necesitas muchas conexiones, pues pones muchas, pero la idea es que uses las mínimas que puedas, por que el servidor de BDD es uno de los recursos que antes empiezan a dar problemas por saturacion (junto con la memoria del servidor de aplicaciones, claro). En un caso como el que me cuentas, si las transacciones son largas y los usuarios trabajan simultaneamente, pues no hay más remedio.
Cita:
Iniciado por stone_neo Ahora en el ambiente de producción del cliente existen cerca de 30 sistemas mas, que tienes igual o mas concurrencia y transacciones mas pesadas de las del sistema que yo doy mantenimiento. Y no siempre vas a poder usar los frameworks k kieras para algun sistema, en nuestro cliente por ejemplo no nos permiten usar ningun framework open source, que por que, eso habria que preguntarles a ellos.
Esto que te explico es con lo que yo tengo que lidiar dia a dia, no quiero decir que esto sea lo verdadero, pero en mi caso, asi funcionan las cosas.
Bueno si, lo de las restricciones al desarrollar tambien es un tema "interesante"... pero bueno, hallar soluciones con las vías que nos dejan es parte de lo divertido del trabajo
.
S!