Row was updated or deleted by another transaction (or unsaved-value mapping was incorrect) error

Q&A
1

Hi!

I have a problem, I get this error:

Row was updated or deleted by another transaction (or unsaved-value mapping was incorrect)

I understand what it causing the problem, or rather i think i understand.

It is caused because i have an object "A" and object "B" both have a "C" object in it. When i collect A and B in a variable, i get it with a version number, and also getting C with a version number. When i save A, then A and also C will get a new version, and saving B is not possible, because hibernate checks the C objects version and it is different than it was when i grabbed B (containing C).

Of course this could come handy, but to me it is the biggest nightmare... In the application i made C lets say it is contsant (not literally, you can alter the object, but on a different form, with different privileges). 

But even if i dont change C object it will get a new version number, and there are a lot of cases where bonita fails to save my A,B etc objects because of this C object version problem. Just so you can understand I have cars and cars can have certain products, normally the products dont change at all. The relation is aggregation, because not just cars can have products.

What could solve this problem? Is there a way to turn off version check? 

Thank you,

Zoltan

2

Hi Zoltan,

Could you post the structure of your BDM. I have the feeling that the issue comes due to the usage of composition instead of agregation of the same object.

 

Could you apply that change and give us feedback?

3

Since nobody answered my question correctly, or didnt get an answer at all in previous questions, i will write down the answer in case someone would have the same issue.

The main problem is that the Bonita really likes to run jobs in parallel. To solve this problem you need to understand how hirbernate/spring works.

First of all the reason this error appears:

It doesnt have to do anything with composition/aggregation setting, the reason is the eager (alway load)/ lazy (only load when needed) is set to eager, in this case hibernate versions all objects under the currently saved object that has eager loading. This can be manipulated in the entity class, however, in Bonita you dont have the option for that.

This is the annotation for the lazy setting with aggregation:

@ManyToOne(optional = true, fetch = FetchType.LAZY, cascade = CascadeType.MERGE)

And this is the the annotation generated by Bonita if you have an eager with composition:

@OneToMany(orphanRemoval = true, fetch = FetchType.EAGER, cascade = CascadeType.ALL)

 

To be honest i didnt check what will be generated, if i changed the aggregation to composition, because it is a given in the structure, the only thing that i can change without re planning the whole structure is the eager/lazy setting.

In this annotation, the CascadeType setting is that is responsible for my problem. If ALL is set, then all child objects will be versioned if you save the parent.

When i had my problems, i had objects with aggregation set with eager, it was convenient to use in the front end, but it caused the error mentioned in the question

To avoid this error, you should always use lazy loading (only load objects when needed), otherwise you might get this error.

I tested this and could reproduce this error, by starting to task parallel with two different parent objects with the same child object, and if i used eager i got the error, and the child got versioned, if i used lazy loading, then everything worked fine.

To sum it up:

Error cause: Eager/Lazy setting in Bonita, with eager the CascadeType is set to ALL, and will version child objects which will cause transient exception in parallel use of the parent object.

To solve this: Use Lazy loading (only load when needed in bdm setting), and for the front end you might need to create an API extension.

Edit: With composition setting this could be avoided, since one child will belong only to one parent, and another parent cant have this object, so even with eager, it will work fine as long as you use composition. However if you use aggregation then is it is almost necessary to use lazy (only load when needed setting).

Regards

Zoltan

4

In my current problem i could solve this in the script by using the *DAO.findByPersistenceId(C.persistenceId) function. But i dont think this should be the best approach, or is it?

5

Hi,

Our BDM model is quite big, but i dont think it is the case of composition/aggregation setting. The studio doesnt let you use a composition child object in another class, so i even if for some reason we where making this mistake, the studio wouldnt let us do that.

I already solved this problem, i will ad it as an answer because nobody is talking about this in the community, i asked this at least 3 times, and no correct answer.

Edit: With composition setting this could be avoided, since one child will belong only to one parent, and another parent cant have this object, so even with eager, it will work fine as long as you use composition. However if you use aggregation then is it is almost necessary to use lazy (only load when needed setting).

Zoltan