The first mistake I have was start coding too fast. I started following a tutorial, but I confess that I focused too much on code, an little on the theory. Following that tutorial I set a OneToMany relationship between an user and his accounts. Somehow, I thought that the account list in the user side would get filled automagically, driven by the annotations I was using. As the accounts got dropped from the database when I deleted an user, I thought everything was alright, and I didn't think about too much.

Yesterday, doing some tests on the category entity, I found that in a child-parent relationship, the child didn't have its parent category updated when I deleted that parent category. In the database I had set "ON DELETE SET NULL", and looking at the database while performing the tests showed that it was working there. But Hibernate didn't seem aware of that behavior, and the link to the old parent category still appeared in the child. That led me, after some tries, to understand how cascading was supposed to work and how badly I was using it. I had several cascading annotations in the ManyToOne side of some relationships, which meant that when I made a change on the many side, the other side was getting affected. And that wasn't the behavior I was expecting!

I went to the documentation to learn how should annotations work, and what did they mean according to the context they were used in. After that, I removed most of my annotations, and made some changes, in the update and delete methods in my DAOs to spread the changes when that was needed.

Now, an user has a list of accounts. When an account is created, it sets a reference to the user who has it. And makes that user add it to his account list. When an account is deleted, it makes the user remove it from the account list. As the account operations have a reference to an account, Hibernate is responsible to update that reference.

The categories behavior is similar. When a root category is created, it creates an empty list of child categories. When you add a child category to a parent category, you add that child to his parent list. When deleting the parent, you have to go through the list, updating all the references in his children. When deleting a child, you have to remove it from his parent list.

After these changes, everything is working now. I know that some of the tests I've done are too bound to my interpretation of the behavior they have to show, and so they may be wrong. But at least I get rid of part of the errors I still have.

As I'm not sure if those explanations were clear enough, I'll try to synthesise here:

• Deleted entity passed to persist. One entity, supposed to be deleted, is still referenced / accessed. In my case, I had a problem with "cascading". The behavior I expected was "on delete cascade" and "on update cascade". I have those constraints well in the database, but they weren't right in the Hibernate annotations. After I changed that, the error stopped. While I was searching why I was getting this error, I've seen people whose problem was different. They had, let's say, a list of entities. Those entities were related to others, and, when deleting, they had to take care of deleting both the link and the persisted entity. This was the most common scenario of this problem, and is better explained here, for example.
• Detached entity passed to persist. One entity, which is supposed to be up to date but is not, is passed to persist. In my case, I was trying to create an entity (an Operation), related to another (the Account where that Operation was taking place). The persist action was failing because my version of the Account was incorrect. The solution was just to update the entity.
• Id to load is required for loading. Trying to access an entity without giving an actual identifier. In my case this was the easiest problem: I was calling find passing a non initialized long. Passing the correct, initialized values fixed the problem.