Cascade internal implemenation uses HashMap; breaks typical object relationship management code

Description

The problem seems to be that no matter what sort of concurent-safe collection one uses to implement a mapped collection, Hibernate's internal cascade mechanism uses a HashSet when cascading; This breaks a typical design pattern used for consistency:

To replicate:

inside A.java

inside B.java

Now, if somebody tries to remove an instance of a B, the preRemove method causes the parent A to delete that B from its set myBs. Just what is wanted.

If someone tries to remove an A, the remove will cascade to all the elements of myBs, also as desired. But when this cascaded removal of the B encounters the preRemove code and tries to remove itself from the A, we get a concurrent access violation. Stack trace shows that in spite of the field myBs being defined as a concurrent-safe class, Hibernate is internally using a hashMap to do the cascade.

Environment

4.1.8 on Postgres

Assignee

Unassigned

Reporter

Chris Owens

Fix versions

None

Labels

backPortable

None

Suitable for new contributors

None

Requires Release Note

None

Pull Request

None

backportDecision

None

Components

Affects versions

Priority

Major
Configure