[
https://issues.apache.org/jira/browse/OPENJPA-2611?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Richard Zowalla resolved OPENJPA-2611.
--------------------------------------
Resolution: Fixed
Already fixed on master: db0926b22 and a6ff4483e (both on master) stop the
cascade in bulk DELETE and clean up owned tables in SQL. The cases that still
run in memory (multi-table candidate, listeners, composite PK) are documented
in migration_considerations.adoc:166-215. Closing; please reopen if this still
happens with OpenJPA 4.x.
> Bulk operations behave inconsistently to JPA Spec and OpenJPA documentation
> ---------------------------------------------------------------------------
>
> Key: OPENJPA-2611
> URL: https://issues.apache.org/jira/browse/OPENJPA-2611
> Project: OpenJPA
> Issue Type: Bug
> Components: jdbc
> Affects Versions: 2.1.1
> Environment: OpenJPA 2.1.1 in Websphere 8.0.0.10 on IBM J9 VM 2.6
> Reporter: Jakob He
> Priority: Major
>
> During mass data tests we discovered an undocumented behaviour in OpenJPA
> when executing bulk operations via JPQL. OpenJPA decides to execute the bulk
> operation completely in-memory if it detects either a CascadeType.REMOVE
> annotation or a mapping to a different table on a field (1). The
> in-memory-delete loads all entities which should be deleted into memory at
> first and then deletes them manually to make sure no constraints are
> violated. According to comments inside the OpenJPA source code it is clearly
> stated that bulk deletes won't be performed with server-side operations if a
> mapping lies in multiple tables (2).
> Although this behaviour might be seen as a feature of OpenJPA, it is actually
> a bug in either your documentation or your implementation regarding the JPA
> specification. The official OpenJPA documentation says that "a (bulk) delete
> operation only applies to entities of the specified class and its subclasses.
> It does not cascade to related entities." (3) - however, the actual
> implementation *will* cascade on a CascadeType.REMOVE annotation or a
> orphanRemoval=true property (that's why OpenJPA performs the in-memory
> delete). The JPA 2.0 specification contains exactly the same definition as
> your documentation.
> We stumbled upon this behaviour while investigating an OutOfMemoryError that
> occurred during a load test in which OpenJPA should delete 1.4 million
> records from our database. Although we discovered this bug in version 2.1.1
> of OpenJPA, a short look on GrepCode shows that the relevant source has been
> present at least since 1.x and is still present in 2.4.0. It would be
> desireable if this behaviour is at least documented outside of the source
> code, since users of Hibernate or EclipseLink would not expect in-memory
> operations and might experience OutOfMemoryErrors like we did. Otherwise it
> would be even better if OpenJPA runs always a server-side bulk operation to
> conform with the JPA specification or provide at least a documented
> configuration option for disabling the in-memory operations. However, this
> would also mean, that existing users who rely on the current implementation
> might get problems with server-side constraints in the future.
> If you know any way of disabling this behaviour without updating the OpenJPA
> library, please let me know. The only workaround we currently see, is using
> native SQL queries for bulk deleting records.
> Sources:
> (1):
> http://grepcode.com/file/repo1.maven.org/maven2/org.apache.openjpa/openjpa-jdbc/2.4.0/org/apache/openjpa/jdbc/kernel/JDBCStoreQuery.java#JDBCStoreQuery.getTable%28org.apache.openjpa.jdbc.meta.FieldMapping%2Corg.apache.openjpa.jdbc.schema.Table%29
> (2):
> http://grepcode.com/file/repo1.maven.org/maven2/org.apache.openjpa/openjpa-jdbc/2.1.1/org/apache/openjpa/jdbc/kernel/JDBCStoreQuery.java#JDBCStoreQuery.isSingleTableMapping%28org.apache.openjpa.jdbc.meta.ClassMapping%2Cboolean%29
> (3):
> http://openjpa.apache.org/builds/2.4.0/apache-openjpa/docs/jpa_langref.html#jpa_langref_bulk_ops
--
This message was sent by Atlassian Jira
(v10.3.26#10030026)
