Cascading save (JPA merge()) of a transient entity in a UserCollectionType yields duplicate INSERT -------------------------------------------------------------------------------------------------- Key: HHH-6630 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-6630 Project: Hibernate Core Issue Type: Bug Affects Versions: 3.6.7, 3.6.6 Reporter: Joachim Breuer Attachments: UserCollectionDuplicateInsert.tar.bz2 When saving a new (transient) entity by cascading from a JPA merge() operation on its parent, Hibernate will generate [at least] two INSERT statements for the new entity when it is held in a UserCollectionType. When not specifying a UserCollectionType, the problem does not occur. The UserCollectionType (for the test case) appears as simple as at all possible, it simply delegates to an ArrayList. The example/test case attached demonstrates the problem; the HibernateCollectionTest succeeds (and uses a model without the UserCollectionType internally), the UserCollectionTest fails with exactly the same operations, but the UserCollectionType (/jpaSandbox/src/main/java/de/soflimo/sandbox/model/impl/CustomList.java) specified in the mapping. A few notes about the example: - I'd expect this to run straightforwardly (using maven). - I'm not familiar with Hibernate outside of a Spring/JPA context, so that's what the test case uses. Feel free to further simplify the test case. 1. 'getFolderXXX()' at the very top of the Tests returns a (detached) freshly-created, empty Folder instance. The underlying FolderService.createFolderXXX() run in a transaction [configured using Spring] which ends when returning from the createFolderXXX() methods; i.e. the 'folder' instance in the test methods must be thought of as 'detached'. 2. folder.addDocument() modifies the detached folder entity in-memory, by inserting a new (transient) Document entity into its documents collection. 3. save(folder) implemented by FolderService.save() performs a JPA merge() on the detached and modified folder. This, again, is executed within a transaction. When using the built-in hibernate collection handling, this succeeds; but when specifying the CustomList UserCollectionType in the model mapping, committing this transaction fails because it tries to INSERT [at least] a second row with an identical uniqueKey. This problem is developing into a blocking issue for us, I'll be happy to try any workarounds and be of further assistance in finding and fixing the cause of this. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira