What is the challenge ?
A storage must be persistent, so application recycle would not cause any data lost.
Storage must handle high load, in-memory caching is required.
Can we achieve that without customization?
Can we just use OOB Sitecore functionality?
Technical sketch
- It make sense to create a table (key-value) inside database.
- Caching layer must respect data changes, as well as have defined limit
- All interactions should be done via database provider, so one can handle changing database engine, and create tests if needed.
How To inside Sitecore ?
Sitecore CMS has Database Properties mechanism encapsulates everything aforesaid:
Sitecore.Configuration.Factory.GetDatabase("core").Properties["customKey"]=value
This mechanism is used internally f.e. to maintain Sitecore Client User tickets, publishing and indexing metadata.
Database Properties logic is inside 'Sitecore.Data.DataProviders.Sql.SqlDataProvider' class ( 'GetPropertyCore', ' SetPropertyCore', and 'RemovePropertyCore' methods ), so please feel free to check exact implementation via any reverse-engineering tool.
Implementation details
Each Sitecore database has 'Properties' table that represents key-value storage:'Database property changed' event is added into EventQueue once property value is changed. As a result other Sitecore Instances eliminate modified property from cache, and would reload it from database directly on next call. Given SQL could be used to check what is written into EQ:
- SELECT * FROM [EventQueue] WHERE [InstanceType] LIKE '%PropertyChangedRemoteEvent%'
Summarize
Sitecore provides key-value storage synchronized across all instances out of the box.The price to forward modification from one instance to other is an extra row in EventQueue.
Frequent properties modification could produce a large amount of EventQueue entries, so please use the feature wisely.
No comments:
Post a Comment