EntityNotFoundException: Bean not found during lazy load or refresh

[xu lakxe]

Hi Rob,

The problem I encountered is this, create two transactions A and B successively and then operate the same entity at the same time. One update, one query, I observed that the cache was also cleared after update transaction A was submitted. Then transaction B performs a query, but it gets the old data and adds the old data to the cache, and subsequent queries always get the old data. 

  If transaction A is a delete operation, the problem will cause the ebean to continue to throw EntityNotFoundException: Bean not found during lazy load or refresh. Because the old data that has been deleted is always stored in the L2 cache.

 I use mysql. I think what I encountered is a mysql-specific problem.

 I think it may be a transaction isolation problem, but I am not sure whether ebean should take some action to solve this problem. Because the old data in the L2 cache will always cause program errors. 

This problem is very occasional, I tried to provide a test case, please see the 'textMysqlLazyLoad' case in this project:

https://github.com/lakxtxue/ebean-lazy-load

Thanks.

[xu lakxe]

Hi Rob, do you have time to read the test cases I provided?

I solved it by modifying the mysql isolation level
from'REPEATABLE_READ' to'READ_COMMITED'.

The ebean seems to do the right thing, but in the'REPEATABLE_READ'
isolation, the ebean will inevitably cause the above problems and lead
to program errors.
Hope to get your opinion.
Thank you

xu lakxe <lakx...@gmail.com> 于2021年1月20日周三 下午4:04写道：

> --
>
> ---
> You received this message because you are subscribed to the Google Groups "Ebean ORM" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to ebean+un...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/ebean/62e69bf7-cb42-4573-950b-c259704e5223n%40googlegroups.com.

[Rob Bygrave]

I had a quick look but didn't get to run it.

> I solved it by modifying the mysql isolation level from'REPEATABLE_READ' to'READ_COMMITED'.

That is interesting and I was wondering about that. Note that READ_COMMITTED is the expected isolation level from a JPA perspective and for me I would say from a Postgres and Oracle database perspective (default isolation level). Noting that higher isolation levels have a "window" where optimistic locking does not work (potential for lost update) - conceptually developers need to start using pessimistic locking (actual DB row locks) at isolation levels higher than READ_COMMITTED.


The thing to try I think would be to turn on:

ebean.notifyL2CacheInForeground=true

Cheers, Rob.

To view this discussion on the web visit https://groups.google.com/d/msgid/ebean/CADiyVGe7R0uh3dkfVQSCD8LJ0x7dhpj6oXtY6WyLEptpJf8X2A%40mail.gmail.com.

[xu lakxe]

Hi Rob,

Based on your response, I think I should use the READ_COMMITED isolation level.

ebean is indeed the best java ORM framework I have ever used, bar none.

thank you very much

[Rob Bygrave]

> use the READ_COMMITED isolation level.

Yes. That would be a very strong recommendation.

Cheers, Rob.

To view this discussion on the web visit https://groups.google.com/d/msgid/ebean/beb77d0f-b434-4288-804a-64545ae4ced2n%40googlegroups.com.