What Object cache does is stores metadata about SharePoint Server objects (like SPWeb, SPSite, SPList, etc.) on the WFEs. When a page is rendered, if there is data that needs to be retrieved through these objects, the SQL Server will not be hit. Features of SharePoint that uses Object cache are publishing, content query web part, navigation, ...
After banging my head around for some days, the problem was solved by flushing the blob cache.
This is the command I used on the Front end server
$webApp = Get-SPWebApplication "<WebApplicationURL>"
Write-Host "Flushed the BLOB cache for:" $webApp
Ok I have finally found the root cause for this issue.
I believe this is a bug relating to either Windows Server 2019, SharePoint Server 2019, or a combination of the both.
Basically, the application pool accounts do not have sufficient permissions to create BlobCache folders in a vanilla install of SP2019 (specifically on Server 2019).
There are 2 key ...
You should create a big array that you'll then store into the sessionStorage. And your code is not really clear.... based on what you asked I rewrote it:
// we suppose that "index" is the "Title" we are looking for
var index = "My Title";
// get the data from sessionStorage
var list = sessionStorage.getItem('PrivacyStatementsList');
Object cache - metadata, WP queries of external sources, search boxes, quick launch, breadcrumb
Default is on
Configurable through GUI or web.config per each SC
BLOB cache - binary large objects like images or CSS files, stored on WFE disks
Default is off
Configurable through GUI or web.config
Page (output) cache - for whole pages to load them faster ...
There are various ways:
// Stop Caching in IE
// Stop Caching in Firefox
or you could use the @Output property:
Here you can find all ...
I encountered this same problem in SharePoint 2016, and was finally able to resolve it by configuring output cache profiles.
Output Cache Profiles are applied at both the site collection level (by clicking the Site collection output cache link under Site Collection Administration) and the site level (by clicking Site output cache under Site Administration).
If they are 5 different apps from 5 different developers and each is using its own local copy of Jquery then there is nothing you can do. On the other hand, if you are the developer of those 5 apps just use put all common files on a central server and reference the files from there. Browser caching works based on the domain where the file is pulled from.
You can use query string for every new JS/CSS files like ?v=GUID to trick the browsers, which definitely will ensure new CSS/JS will be loaded every time you perform a new deploy. Otherwise, there is no clean solution to avoid browsers' behavior.
/Style Library/my_js_file.css?v=<current date>
It looks like you are calling CSSRegistration on a css file that doesn't exist. CSSRegistration is used to ensure that a css file will only be loaded once even if it is referenced multiple times. It can also allow for conditional loading of stylesheets depending on what browser is being used to view the page.
Have a look through any masterpages or page ...
Good news! The July 2019 CU for SharePoint 2019 finally fixes this misbehaviour. Blob cache now works for SharePoint Server 2019 as it is supposed to.
Check the details:
The caches are only created when the first Distributed Cache server is created (this is usually the SharePoint server you create the farm from). What this means is, if for some reason you encounter a failure during the creation of a cache, it is not possible, in a supported way, to create the cache post-deployment. Unfortunately it will not be apparent if ...
Yes it is a standard server in the farm, that just is dedicated to run Distributed Cache Cluster
This is handled by AppFabric, the technology behind Distributed Cache Service
Et is EXPLICITLY forbidden to use the AppFabric cache cluster for your own apps:
Important: If you are using custom applications in SharePoint Server
2013 which use the AppFabric ...
The best bet is to use SPWeb property bag. This caches the data and shared across the farm and will persist through server reboots.
For adding a new property you can use following code block
// unsafe updates are required to be able to write to the property bag
To start of, caching the SPListItemCollection is a bad practice and you should not implement it at all. You will find all the necessary information at Best Practices: Common Coding Issues When Using the SharePoint Object Model. You should store the data in a DataTable and cache the DataTable instead.
Apart from that, the entire scenario sounds like a really ...
Next time you make changes to your CSS file, create your own rev/version tag where the CSS file is being referenced (probably your Master Page). This way the browser will break the cached CSS and re-retrieve thinking it's a new file.
<link href="/styles/style.css?rev=03_27_2014_v1" type="text/css" rel="stylesheet" />
Here is my interim solution: using HttpContext.Current.Cache.
There is a good helper class here: http://johnnycoder.com/blog/2008/12/10/c-cache-helper-class/.
If I don't get a better solution for this, I'll mark this as the answer.
Can you deliver the data in chunks? Such as an infinite scroll or paging? If that's the case, I'd say just use AJAX and oData to grab more data as it's needed.
Also, how static is the content? Does it change often? If not you could always try browser caching or offline storage.
Simply put, we might need more information before we could better help out :-)
This blog post explains in a verbose, but clear, fashion about how to appropriately configure blob caching for SharePoint. For example:
Failure to specify a max-age attribute in the BlobCache element of the web.config will result in the default value of 86,400 seconds (24 hours) being used. Use of a non-zero max-age attribute will result in the attachment ...
If they have the namespaces you need, go for it.
You've tagged it with '2013', are you using SharePoint 2013? Make sure that the AppFabric Cache cluster you're using is not the one SharePoint 2013 using, make sure it's on a server that's not one of your SharePoint servers and one that you're maintaining on your own. It's unsupported to use the AbbFabric ...
Try setting query.Webs:
query.Webs = "<Webs Scope=\"SiteCollection\" />";
See if that makes a difference.
I also found another site that might help:
Cache misses are mostly likely to happen because of insufficient memory as they all are stored in Ram. If not then mostly cause must do with the Cache configuration. I would suggest to try the different settings specified for the object cache like changing the maxSize directly in the web.config etc. in the article below,
"Cache miss for query Web" may be the answer. You may be looking at the ULS log for the wrong portion. I would look at the ULS log for the first successful run and see if there is not a cache miss for the list that results in a cache dump for the list you are querying.
You may be able to remedy by changing the query from server side to client side. If I ...
Configuring object cache settings
The object cache settings can be configured at the site collection
level in the user interface by a site collection administrator, and is
on by default. The maximum cache size can be configured at the Web
application level on the front-end Web server to place a restriction
on the maximum amount of memory that ...