[MGNLCACHE-83] Implement CacheKeyGenerator Created: 05/Feb/15  Updated: 25/May/15  Resolved: 19/Feb/15

Status: Closed
Project: Cache Modules
Component/s: None
Affects Version/s: None
Fix Version/s: 5.4

Type: Improvement Priority: Neutral
Reporter: Roman Kovařík Assignee: Roman Kovařík
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
dependency
depends upon MGNLCACHE-70 Change flush policy workspace registr... Closed
is depended upon by MGNLADVCACHE-44 Allow to use a custom cache key gener... Closed
Template:
Acceptance criteria:
Empty
Task DoD:
[ ]* Doc/release notes changes? Comment present?
[ ]* Downstream builds green?
[ ]* Solution information and context easily available?
[ ]* Tests
[ ]* FixVersion filled and not yet released
[ ]  Architecture Decision Record (ADR)
Date of First Response:
Epic Link: DPC

 Description   

Allow to use a custom CacheKey/CacheKeyGenerator per cache policy.



 Comments   
Comment by Jan Haderka [ 19/Feb/15 ]

DefaultCacheKey.hashcode()
ummm, int max (2to31 -1) is 2,147,483,647
your hashcode leads to 31to7 which is 27,512,614,111
and unless I'm mistaken that leads to int overflow and most likely fails to achieve main objectives for hashcode impl

  • minimum of objects sharing the hashcode (i.e. no repetition and even distribution over whole range of int)
  • return result asap (i.e. minimize number of calculations made)

I would also argue that as a key cache key should be immutable. First it's good practice, second it does wonders for object allocation in memory of VM

Default
While I understand that it is convenient to tie policy to key generator, I still have to wonder if we would not be better off actually injecting generator into the policy. WDYT?

Generated at Sun Feb 11 23:52:02 CET 2024 using Jira 9.4.2#940002-sha1:46d1a51de284217efdcb32434eab47a99af2938b.