Can anyone provide a good example scenario for using "Org level platform cache" versus custom settings? I can understand when you would use session cache but I am still trying to come up with an scenario in which Org level platform cache would be preferred over custom settings
[SalesForce] Org Cache VS Custom Settings
Related Solutions
I'd say it depends on how you are using the Map<String, CustomSetting__c> that getAll()returns and how may list records there are.
If you are looping over the map values() searching for a single record based on a field other than the Name then SOQL would probably serve you better as you could just grab the required records.
One thing to note with the SOQL approach. It will cost you one of your 100 synchronous SOQL queries governor limit. Where as the cached getAll() is free from that but may not have the absolute latest data. I assume that the caching is only for the duration of the transaction (TODO: confirm this is actually the case). See the comment from @ca_peterson that the underlying implementation is based on memcached.
If you can access the Map by the Name key then the Map has some good advantages over SOQL if you need to pick out several values. Even better would be pulling out individual CustomSetting__c records by name using getInstance(dataset_name)
I'm going to go out on a limb here and say that the cache will be much faster than a SOQL query in getting a raw list of all the possible list values. Of course, it's hard to say what other caching Salesforce has got going on internally.
I did a quick test with a list custom setting to get a list of all values:
- SOQL query for all fields: 19:22:33.249 to 19:22:33.251 = ~2 ms
- .getAll().values(): 19:22:33.251 to 19:22:33.252 = ~1 ms
There is a slight advantage to the cache here, but that doesn't take into account how much extra processing you will need to do on the results.
So, in conclusion, it depends on how many of those list custom setting values you want and if you can access them by name. You will need to try both approaches on your data to see which works best while taking into account if you can spare the extra SOQL query.
I have found answer for my question by Allocating space to Session Cache and Org Cache Allocation . I have forgot to change the value of Session Cache Allocation and Org Cache Allocation from 0 to some other value. without that it is not working..
Above session cache code only works if your created new Platform Cache. If you don't know how create a Platform Cache, Follow below link one by one
First Follow this link to activate Request Trial Capacity
Second Follow this link to create new platform cache
If your finished with above two step then click on edit on platform cache which your newly created, Change trail value 0 to 5 in Session Cache Allocation and Org Cache Allocation and save it.
Best Answer
The two types of data stores are used for entirely different things. The platform cache is temporary cache, much like what a web browser uses to look up recently used data, while custom settings are more of a permanent cache, which basically means it won't go away until someone tells it to.
Custom settings are great for simple types of data that should retain their values indefinitely. For example, the next auto-number value for triggers to use, or the user's preferred default email template, or the encryption key for some custom encryption methods used to protect some data. These are things you probably don't want the system to forget, so they belong in custom settings. Note that custom settings only hold a handful of data types that must be defined beforehand.
Platform cache is used for complex types of data that can reconstructed if they're lost. For example, if you have a custom object that defines various menu items in a hierarchy, you might want to render this menu just once, stick it into some platform cache, and use it indefinitely until it's invalidated. This allows the page to load faster when there's a cache hit, improving overall performance for the majority of the time. It also has several other severe considerations, including no support for concurrency, persistence, and so on.
Since the cache might grow stale or be overwritten at any time, you should avoid placing any data in there that you cannot easily reconstruct. The cache, however, does support any type of serialized data that you can use, including collections, custom classes, and so on. This means that you get to skip almost all of the CPU and database time you'd incur by rebuilding the object every time your page is loaded from scratch. This can even reduce the View State of your page, because the data can be pulled directly from cache.
Org wide cache, while probably more difficult to conceptualize than the session cache, can still benefit users that share a common data set. Keep in mind that session cache refers to a single user, while org wide cache refers to anyone in the system. You can still break down org wide cache into smaller pieces using keys and/or partitions to share the cache across various users. For example, you might render menus for each profile, and you could store them in various keys like "local.00eXXXXXXXXXXXX.menu", allowing each profile to have their own unique menu that could be cached.
In general, you just need to ask yourself a two simple questions: "Do I need this data to persist in the database? (Yes: Custom Settings)" and "Do I just need this data to improve application performance? (Yes: Platform Cache)". There's usually always one right answer. Once you decide to use cache, then you can ask "Would this data best serve one user? (Yes: Session Cache)" and "Could this data be used across multiple users? (Yes: Org Cache)".