3 ms·
Do you mean that when you get an update, you both write to the database and perform an update in the cache? If so, you would want it to be a transaction so that
by laut 17y ago
Do you mean that when you get an update, you both write to the database and perform an update in the cache? If so, you would want it to be a transaction so that the cache and database is not out of sync.
Maybe a write cache, like on hard drives with write back caching. If you first wrote the update to a cache (queue of updates). Then it would be written to both the cache (cached html for instance) and database in one transaction.
But I think it sounds like more trouble than it's worth.
- alexandros 17y agotransactions are unnecessary, unless you are looking for 100% consistency between cache and database at all times. Usually this is not the case and if it is, you will have extremely serious problems scaling. All i'm saying is: If you have an update that you know will invalidate some cached pages, why invalidate them and then rerender them from the database once the update is commited instead of updating them directly. and lazy queueing the update, taking the load of the database (less pressure to commit instantly, and less reads). In the facebook inbox example, you know that a new message to the user will increase their message count by one. Just update the cache directly with this new info. When/if it explodes, by all means, rerender everything.