I wrote a code draft of a cache manager with the purpose of storing entity instances in memory in order to avoid costly and repeated direct fetching of the database.

-
I wrote a code draft of a cache manager with the purpose of storing entity instances in memory in order to avoid costly and repeated direct fetching of the database.

Once cached, the cache manager monitors the database via events, asynchronously updating or removing the cached instances in order to keep the database and cache information synchronized.

https://gist.github.com/dipold/9413e70deaca977b5f2528f4f4e23135

I am sharing to get opinions or improvements about it or if you already know any project that does the same (I saw some things integrated into some ORM frameworks only)

https://gist.github.com/dipold/9413e70deaca977b5f2528f4f4e23135

Comments

  1. Jeroen Wiert PluimersJuly 3, 2018 at 5:49 AM

    Why does it have hard bindings to these?
    function GetCountry: IConstraintCountry;
    function GetCustomer: IConstraintCustomer;

    ReplyDelete
  2. Rafael DipoldJuly 3, 2018 at 5:57 AM

    I would prefer that there was a way to do something like:
    FCacheManager.Get.ByName('Brazil');
    FCacheManager.Get.ByDocument('123456');

    But, like each IModel has your IConstraints definitions, and Delphi doesn't support generics wildcards, I didn't find a way to do that..

    ReplyDelete
  3. Bernd MaierhoferJuly 4, 2018 at 1:54 AM

    A cache manger would be part of an ORM - TMS Aurelius does this and much more. Maybe you would like to have a look.

    ReplyDelete
  4. Rafael DipoldJuly 4, 2018 at 4:02 AM

    yes, I agree, and I know Aurelius, but we have a lot of legacy code and a small ORM developed internally before the Aurelius exists, so, for now, this is the only way ..

    ReplyDelete
  5. Lars FosdalJuly 4, 2018 at 11:03 PM

    My own hard learned experience is that caching db content is a significant risk. The more concurrent processes (or even threads), the higher the risk for the cache being stale, so you would have to think carefully about how many potential paths for change there are for a table.

    ReplyDelete
  6. Rafael DipoldJuly 5, 2018 at 4:13 AM

    For now, for concern, I'm only caching simple register tables, such as cities, countries, customers, suppliers, tax settings, etc. which are not constantly changed.

    And a trigger in the tables sends an event to the application that updates the cache asynchronously if a record is updated or removed from the database.

    Only with these caches has the performance significantly improved since these tables are constantly selected.

    ReplyDelete

Post a Comment