Al utilizar Tomcat con MySQL, ¿cuál es la relación entre la configuración de poolPreparedStatements en la configuración de Tomcat DataSource (creo que proviene de DBCP) y Connector/J cachePrepStmts? ¿Cuál es la configuración óptima?Pooling PreparedStatement en Tomcat con MySQL
Respuesta
poolPreparedStatements es una configuración para el conjunto de conexiones JDBC de Tomcat y cachePrepStmts es una configuración para que Connector/J indique a MySQL que guarde en caché las instrucciones preparadas. Dos cosas completamente diferentes. cachePrepStmts es una configuración por conexión, pero Connector/J no se preocupa de si se está conectando directamente a un grupo de conexiones de base de datos oa MySQL, pero cachePrepStmts funciona de la mejor manera con conexiones persistentes (por ejemplo, grupos de conexiones). Usar cachePrepStmts con un grupo de conexiones es la configuración óptima. Usar poolPreparedStatements en Tomcat es abrir una lata de gusanos de administración de memoria (revisa los documentos de Tomcat para esta configuración y verás). En realidad, es mejor dejar que MySQL guarde en caché las declaraciones preparadas y permita que Tomcat agrupe las conexiones y no intente hacer que uno haga el trabajo del otro.
No estoy seguro si esto ayudará, pero eche un vistazo a the accepted answer of this question.
- 1. Almacenamiento en memoria caché PreparedStatement en Tomcat
- 2. Insertar datos binarios en MySQL (sin PreparedStatement)
- 3. Java: inserte varias filas en MySQL con PreparedStatement
- 4. Perl Connection Pooling
- 5. consulta SQL ejecutar con PreparedStatement
- 6. PreparedStatement con Statement.RETURN_GENERATED_KEYS
- 7. Declaraciones preparadas junto con Connection Pooling
- 8. mongodb connection pooling
- 9. ¿Qué caracteres escaparán PreparedStatement?
- 10. PreparedStatement setNull (..)
- 11. Entity Framework y Connection Pooling
- 12. NHibernate y ADO.NET Connection Pooling
- 13. Mysql Drop Table como PreparedStatement no funciona para mí
- 14. Java Crosstab - preparedstatement query
- 15. MySQL no volver a conectar con JNDI Tomcat 6
- 16. SQL Server Temp Tables y Connection Pooling
- 17. setObject() método de PreparedStatement
- 18. pymongo connection pooling y solicitudes de clientes
- 19. PreparedStatement y setTimestamp en JDBC de Oracle
- 20. PreparedStatement alternativa dentro de JPA?
- 21. Java PreparedStatement recuperando la última ID insertada
- 22. ¿cómo desactivo el registro en java c3p0 connection pooling lib?
- 23. Tomcat con resorte
- 24. SQLException con el grupo de conexiones Tomcat 7.0 JDBC y MySql
- 25. Insertar datos de blob en Java utilizando PreparedStatement
- 26. Relación entre "cerrar" para PreparedStatement y Connection?
- 27. ¿Cuándo debería cerrarse un PreparedStatement java?
- 28. ¿Qué debo cerrar primero, PreparedStatement o Connection?
- 29. Cambiar zona horaria en Tomcat
- 30. "PermGen" recurrente en Tomcat 6
Por lo tanto, está sugiriendo que Connector/J hará un mejor trabajo que DBCP para agrupar declaraciones preparadas, ¿verdad? Además, encuentro esto confuso: "Connector/J no se preocupa de si se está conectando a un grupo de conexiones de bases de datos o directamente a MySQL". Connector/J está en un nivel más bajo que DBCP, por lo que siempre se conecta directamente a MySQL, ¿no? – ykaganovich
No, MySQL hará un mejor trabajo de almacenamiento en caché de las declaraciones preparadas que DBCP, por lo tanto, establezca el indicador cachePrepStmts en sus conexiones de Connector/J y deje la agrupación de instrucciones de preparación de DBCP sola. Connector/J se conecta directamente a MySQL y DBCP agrupa un grupo de conexiones Connector/J. Creo que el comentario mío que citó fue confuso y confuso. –