Community
Participate
Working Groups
Build Identifier: 20110301-1815 persistence.xml <property name="eclipselink.profiler" value="PerformanceMonitor" /> <property name="eclipselink.jdbc.batch-writing" value="JDBC" /> <property name="eclipselink.target-database" value="MySQL"/> <property name="eclipselink.jdbc.batch-writing.size" value="1000" /> <property name="eclipselink.jdbc.native-sql" value="true" /> <property name="eclipselink.ddl-generation" value="drop-and-create-tables" /> <property name="eclipselink.ddl-generation.output-mode" value="database" /> <property name="eclipselink.logging.file" value="../logs/eclipselink.log" /> <property name="eclipselink.logging.level" value="ALL" /> <property name="javax.persistence.jdbc.driver" value="com.mysql.jdbc.Driver" /> <property name="javax.persistence.jdbc.url" value="jdbc:mysql://localhost?rewriteBatchedStatements=true" /> <property name="javax.persistence.jdbc.user" value="root" /> <property name="javax.persistence.jdbc.password" value="" /> Stacktrace will be appended. Reproducible: Always Steps to Reproduce: 1. enable JDBC batch writing 2. enable PerformanceMonitor
Created attachment 198322 [details] Stacktrace
From an email conversation about this bug: The fault (on our end) seems to lie on reloading a MappedSuperclass (from XML) to an Embeddable class to create our internal metamodel. If they annotated the mapped superclass (rather than map it in XML), it may get them by the problem. Alternatively, it would seem that the embeddable class is only annotated and if it were mapped in XML it could alleviate the problem (oddly enough). So may it may be as simple as adding in XML <embeddable class="blah"/> For the embeddable classes that inherit from a mapped superclass.
sorry.... wrong bug.
Setting target and priority. See the following page for the meanings of these fields: http://wiki.eclipse.org/EclipseLink/Development/Bugs/Guidelines Community: Please vote for this bug if it is important to you. Votes are one of the main criteria we use to determine which bugs to fix next.
Reproduced problem in trunk.
Problem exists because PerformanceMonitor >> startOperationProfile and PerformanceMonitor >> endOperationProfile assume that the passed DatabaseQuery parameter is non-null (calling getMonitorName() on the query). This is not true in batch writing, as ParameterizedSQLBatchWritingMechanism >> prepareBatchStatements explicitly passes null for the query, leading to an NPE: session.startOperationProfile(SessionProfiler.SqlPrepare, null, SessionProfiler.ALL); Proposing that for a null query, the String "(none)" is used within the PerformanceProfiler, for a null DatabaseQuery.
Created attachment 199353 [details] Proposed patch Initial patch / talking point for resolution.
Fixed in trunk (2.4) at revision: 9732 2.3.1 checkin pending.
Checked into 2.3.1 at r9747
Re-opening, based on feedback for currently checked-in fix.
Created attachment 199860 [details] Updated patch Amended code. For a null query, startOperationProfile and endOperationProfile should be started/ended (for the operation), but not for the query.
Changes checked into trunk (2.4) at revision: 9752
Changes checked into 2.3.1 at revision: 9753
The Eclipselink project has moved to Github: https://github.com/eclipse-ee4j/eclipselink
