Any Suggestions? Sometimes remove() works sometimes it doesn't

[Greg Werner]

Hi All

I am using JPA with a non-jta dta source. I have Spring Transactions in place. My provider is org.hibernate.ejb.HibernatePersistence.

Let us say that we have a List of 5 persisted elements. We need to delete all 5 elements from our database. So we grab an Iterator for out List and remove the elements one-by-one. We grab our entity manager factory (javax.persistence.EntityManagerFactory) by @PersistenceUnit and then get the entity manager. Then we do em.remove() where again em is from javax.persistence.

Well, the result is that maybe 3 maybe 4 elements are removed, but all 5 elements are not removed. I am seeing on average maybe a 75% success rate for the remove operation. No failure, no message in my custom logs. If I were to go over a failed element twice with the remove method, it would succeed, so there is nothing particular necessarily about any element (dependecies e.g.) which makes it fail.

Why is it that for my entity manager, the remove statement works sporadically? Anyone seen behavior like this at at all?

[Cameron Wallace McKenzie]

Howdy Greenhorn!

This seems a pretty strange problem. But I'd hate to see your first post go unanswered, so I'll give it a shot.

Could there possibly be another object somewhere with a reference to those objects you are trying to delete? So, on object that references it says 'remove' but some other object subsequently does an update or something, and the entity managed decides not to remove it because some other object is referencing it?

Can you isolate this problem? So, in no other code, you do nothing but load the object, and then do the delete on the four or five objects, and then close the connection. Surely it would work properly in such a scenario, right?

I just keep wondering if someone else is holding a reference to these undeleted objects?

-Cameron McKenzie

[Greg Werner]

Thank you for you reply Cameron. I have searched my code up and down and I can't see any conflicting references.

Let me add some more information, in case it is one of those problems that i should have spotted a long time ago. What am I saying? I am sure it is.

I am seeing some of this behavior on merge statements too now. I do a merge operation it fails. I try the exact same operation, it succeeds. More then likely, the first time I try it after opening my application, it fails, and the second time I try it, it succeeds. In the case it fails, I do an em.find() immediately after the em.merge() to see what the database thinks and the database returns the updated entity. Therefore, the fail occurs later in time as if maybe the em reference used to do the merge just disappears into the sunset never to be seen or heard from again. I try commit() but this does no good.

[Greg Werner]

Cameron and all.

I think we may have solved the problem, sorry to involve you all. Here is what was happening.

There were no error messages at all in the logs with full logging on which was very suspicious. The problem likely arose because of the VPD we have set up, and so it is not an ORM issue at all. I do know what I am doing after all in JPA (maybe???) but this VPD junk is imposed on me organizationally and so it is just something I have to live with. So the database rules are, if you update or delete or persist you have to do some magic to allow the database to change data first. I was calling this every time grabbing an entity manager, but there were still some issues occasionally with getting through this magic barrier.