Aaron

Fixing the issue is possible as I suggested, however, my concern is that it's just fixing the symptom and not the true issue. In fact, it might just result in...

Same here. We are seeing the issue in some spring batch executions which involve many moving parts including multiple threads and sessions. I’ve had a hard time reproducing on a...

Makes sense. I guess my issue is that I’m not sure how to replace it for some of the common scenarios before. For instance, what if you need to fetch...

Actually, after testing some changes, I think the correct fix is to remove the check from the two `validate(...)` calls that take a List and Map in the `GormValidateable`. The...

Actually, playing with it more it seems like the code isn't actually accomplishing what it is trying to do in all cases. Specifically, if you call `save` without a flush,...

It's not really directly part of this change, but in testing I've realized that `deepValidate` is not really that useful in practice. Only the explicit up-front validation in the `save()`...

I think the ultimate solution needs to include having the `DirtyCheckable` implementation reset the `skipValidate` flag if the entity is `GormValidateable`. With that logic in place, an entity safely be...

DirtyCheckable is in core and GormValidateable is in gorm so DirtyCheckable can't directly reference GormValidateable, which would be ideal. I think the two are pretty closely related (or should be...

@demon101 I've been running a custom build with this for awhile in Gorm 6.1.x, but once Grails 4 came out I guess I need to see if this fix is...

We do use `@Cacheable` a good amount but that's at a higher level than this. Our application has a lot of domain classes with to-one reference data is that very...