| EclipseLink not using Tomcat JDBC Connection Pool? [message #1707604] |
Mon, 07 September 2015 20:13  |
 Doug Gschwind
Messages: 17
Registered: April 2012 |
Junior Member |
|
|
Hello everyone,
We are using EclipseLink version 2.6 in conjunction with Spring 4.2, Tomcat 7.0.59, and JDK 1.8.0_45. We do not have a persistence.xml file in place since we use Spring configuration in Java to obtain the data source to our RDBMS (MySQL) and bind that into the EntityManagerFactory we create in Java source code. Our JPA Entities are found fine, appear to be weaved just fine at load time, and our read and write transactions appear to work just fine.
We have set the EclipseLink logging level to FINEST to try and get some additional information about what is taking place at runtime. What we see is that our JPA Entities appear to be weaved at load time just fine, prior to Tomcat reporting that it has fully started up and is ready to begin servicing inbound requests. Then, when Tomcat services the first inbound request, which requires a trip to the database via a JPA query, we see the following things in the Tomcat log file catalina.out where the EclipseLink logging entries are found :
a) The JPA Entities that were weaved previously are woven again. EclipseLink reports that it is deploying our Persistence Unit again.
b) EclipseLink appears to be creating a JDBC Connection for its own internal JDBC Connection pool, rather than using a JDBC Connection present in Tomcat's JDBC Connection pool. This appears to be the case due to entries in the log file that state : "connecting(DatabaseLogin()" followed by
"Connected: jdbc:mysql://localhost:3306/ventana_development" followed by
"Connection acquired from connection pool [read]." followed by
"Connection released to connection pool [read]".
c) Canonical Metamodel processing occurs again.
Please see the attached catalina.out (named EclipseLinkRepeatedWeavingCatalina.txt) file as evidence of the behavior I report above. Note that at 7:34:47 PM on 7 Sep 2015, Tomcat reports "Server startup in 18323 ms". This is the last line in the log file prior to the first inbound request to Tomcat, which occurs a few minutes later at 7:37:29 PM on 7 Sep 2015, in which the first thing reported in the Tomcat log file for that request is that the Persistence Unit is to begin deploying. But, we already deployed the persistence unit prior to 7:34:49 PM.
Thus, I have the following questions :
1) The connection pool named [read] appears to be the default name of EclipseLink's internal read based connection pool. Is that correct?
2) How can we change the configuration of our EntityManagerFactory so that it is using the external JDBC Connection pool that Tomcat has created?
3) Is it possible that this extra processing of deploying our Persistence Unit again is a defect in EclipseLink 2.6 or is there a configuration change we need to make that will eliminate this duplicated processing?
Thank you,
Doug
[Updated on: Mon, 07 September 2015 20:15] Report message to a moderator |
|
|
| Re: EclipseLink not using Tomcat JDBC Connection Pool? [message #1707721 is a reply to message #1707604] |
Tue, 08 September 2015 18:19  |
Chris Delahunt
Messages: 1389
Registered: July 2009 |
Senior Member |
|
|
Hello Doug,
1) read is the default read pool regardless of pool type (internal pool, JNDIConnection etc)
2) This question seems based on faulty assumptions about what is being seen in the logs as what you have done seems to be workin - it appears to already be using a JNDIConnector. A JNDIConnector is the class EclipseLink uses to facilitate getting connections from datasources that are obtained from JNDI. Line 300 in the uploaded file shows the login credentials being used, and show that it is configured to use an unnamed JNDIConnector to connect with a MySQLPlatform platform.
Line 305 and others are showing the connection metadata that is obtained from the datasource itself. In this case, the connection is connecting to jdbc:mysql://localhost:3306/ventana_development which is likely defined in the tomcat server's connection pool. It obtains a connection from the pool and releases it; this is occurring on initialization and so is likely to validate that it can connect. It should not be holding onto to the connection.
3) There are multiple stages in deployment, but EclipseLink will not fully deploy the persistence unit context until it is first accessed. What you see in the logs is a predeployment stage when the server starts up. This stage is where EclipseLink processes the mappings and registers an agent for the entity classes, which is required for weaving. The agent will then run when the classes are accessed by classloaders. Immediately preceding this, EclipseLink is checking the metamodel, which has not been generated, and then we see log messages that the Entity classes are being woven. Unfortunately there is no indication as to what is accessing the entity classes that is causing them to be loaded - this could be Tomcat, Spring, some other component of the application itself.
Later, on line 259 (2015-09-07 19:37:29.418) we see that the application is first being accessed and is using JPA that requires the lazy deployment to complete. This the connection validation already discussed, and triggers the entities to be loaded. I assume that the classloader being used by this thread/persistence unit is different then what might have accessed it before, which will force the classes to be woven; EclipseLink would throw an error or give a message if it found the classes were already woven (as this is the case if you use an agent with static weaving), so they are not already woven.
You can get persistende unit initialization to all be done upfront by using the "eclipselink.deploy-on-startup" persistence unit property ( http://www.eclipse.org/eclipselink/documentation/2.4/jpa/extensions/p_deploy_on_startup.htm ). I don't know how this would be used in Spring.
|
|
|
|
Powered by
FUDForum. Page generated in 0.03082 seconds
] 
Search
Help
Register
Login
Home
