[CUBA 6.7.4] transaction.commit() and entityListeners

Support
#1

Hi!

I have a strange situation in my code behavior. I do changes in my detached entity, then I merge it whith my EntityManager. Entity becomes managed.

After thet i do a transaction.commit() in a block like that:

try(Transaction tx = persistance.createTransaction()){
  ....
  persistance.getEntityManager().merge(entity);
  transaction.commit();
}

and then in my AfterUpdateListener i got my entity with no change in atribute, that i changed earlier in my code.I found this by do a step by step debug and placing a breackpoint at the begginig of my AfterUpdateListener

Can you help me to understend why does it happend? Maybe i do something wrong in my code.

The worst part is that error happends not every time of code execution.

1 Like
#2

Hi,

Your code looks correct (it’s actually not correct at all, but I got the point). So we cannot help you until you give us a test project or more details that would help us to reproduce the problem.

BTW, why do you use AfterUpdateEntityListener in the first place? It’s very rarely needed, are you sure you cannot do the same thing in a BeforeUpdateEntityListener?

#3

I use AfterUpdateEntityListner because i need to perform action after changes commit and saved into the database.

I should send message via ActiveMQ only when all changes saved at DB

#4

But AfterUpdateEntityListener is invoked before transaction commit anyway. The only difference that the record is already in the table and you can for example reference it from another record. But the transaction can still be rolled back for some reason.

If you need a guarantee that the data was written and committed to the database, use AfterCompleteTransactionListener or better send messages from middleware after committing the transaction explicitly.

However, this is not relevant to your initial problem. As I said, we could help if you provide some reproducible scenario.