In Jboss 3.2.5 I experience the following behaviour:
I got two entities, A and B, with 1-n relationship from A to B.
B is set to be deleted when A gets deleted. Underlying db is MySQL. Cascade delete is set on the container level.
When I issue a.remove() everything goes well if the number of Bs connected is smaller than cache size, if it's bigger I got a bunch of messages saying unable to passivate due to ctx lock (it all happens somewhere in the engine as I see from debug) and then finally transaction is rolled back due to this error:
Update failed. Expected one affected row: rowsAffected=0, id=50000000000175
Why is that? How to avoid this behavior? As I can see if the collection to be cascaded is small (smaller than pool size, namely 100 in my case) it works. It SHOULD BE INDEPENDENT OF HOW MANY BEANS ARE TO BE DELETED. Why is that?
