It is interessting that a bug if mine gets rejected (HHH-384: CacheMode Get has no effect on flush) with the explaination that everything works as it should, but it still gets fixed in 3.0.2 --> improved CacheMode.GET/IGNORE, disabled cache put

Can somebody pls explain that to me? Obviously my original assumption was correct and there was a bug and it was fixed in 3.0.2. Why they hell was it rejected in the first place?

bug = something broken and not working as designed
improvement = hm, well, maybe it would be slightly nicer if it worked like this

your bogus "bug" report was based on the completely incorrect assumption that Hibernate can avoid hitting the second-level cache during flush. it can't, and i did not implement that - Hibernate still invalidates the cache for updates and deletes

however, in the particular case of inserts, i can avoid it, so as a tiny optimization, i decided to make that change

Then why didn't you mention that before in the bug and reduce it to improvement, instead of just rejecting it without any explaination.

I would have excepted that and you obviously understood what I wanted anyway. So way just reject it?

And by the way, Do you really invalidate the cache entry (removing it) or do you update the entry. That is an important difference.

I rejected your issue, because there was no bug and your reasoning was flawed.

A few days later, I decided, for a completely different reason, to implement a reasonable performance optimization. By that time the bug report was dead and rejected. If you would have requested this change as an improvement, and provided performance as the reason, instead of claiming incorrect implementation of the semantics of CacheMode.GET, I would have considered it earlier, but you did not, so I did not.


invalidation vs. update ... how is it an important difference? in my view there is very little difference

Invalidation means to remove the entry from the cache.

Updating means to replace the entry.

It is reasonable to assume that updating takes longer than invalidating. It also needs more memory/diskspace in the cache. And in a replacted cluster cache (TreeCache), more data is transfered.

It is again a performance thing. If I update something and know that I don't need it afterwards, it is better to just remove it from the cache than replacing it with values I won't lookup anyway.

I know what the words mean.

I very much doubt there is much difference in performance.

Especially when for truly safe invalidation, you cant simply remove the node, you have to leave at least some entry there with at least the version number.

I don't understand the last piece. If it was removed, the next to look it up, would have to go to the database instead. which is excatly what should happen in such a case. why do I need the entry with the version number?

And I do think that It makes a difference when you update huge amounts of data. I also makes a difference for the cache, as it needs memory for the useless data.

You are not thinking about concurrency.

you mean you need something to lock the entry? but that is the same for remove anyway, isn't it