Child pages
  • [caching] Separate memory cache for each developer
Skip to end of metadata
Go to start of metadata

Imported From: http://groups.google.com/group/in-portal-dev/browse_thread/thread/e66d199a5de6f827#

I've came across one issue, when using Memory Caching in 5.1.0 version of In-Portal.

For example:

  • there are 2 developers
  • each developer uses it's own copy of in-portal code
  • both developers connect to the same database

When all cache was stored in database, then 2nd developer will immediately have changed, that 1st developer have cached. For example, when 1st developer adds new menu item on Front-End, then 2nd developer will see it immediately, since it's cached to "cms_menu" cache. 

In memory caching implementation we have protection against case, when 2 websites on In-Portal will use common cache instead of separate. This protection has side effect, that 1st and 2nd developers now will have own
cache versions and 2nd developer will have to rebuild cache to see, what 1st developer have placed into it (since cache is build based on common database in my example).

This all happens because of each memory cache key has prefix based on In-Portal installation folder full path (FULL_PATH constant), which is different for both developers. If we will replace it with relative In-Portal installation folder (BASE_PATH constant), then it will do us no good, since it will be "/" for most of the sites and as a result will mix up caches of 2 separate In-Portal installations on same server.

I really don't know if this is a bug or a feature, since database is shared, but cached data isn't.

I suddenly got idea, how to fix that:
Here is problematic line $site_key = 'site_serial:' . crc32(FULL_PATH); of kCache::_cachePrefix method. We can do 2 things here:

  1. move it to new class attribute, so we don't have to calculate crc32 for each stored/retrieved key + replace $site_key with that attribute usage;
  2. use BASE_PATH constant instead of FULL_PATH, when we have *$_CONFIG['Misc']['Mode] = 'development';* (new config variable) set in config.php file.

Related Tasks

INP-707 - Getting issue details... STATUS

9 Comments

  1. Hi Alex,

    This is both bug and feature since moving site serial to a class attribute
    will make it more efficient while adding new development mode makes it more
    as feature. I think we can add test and add this to 5.1.1-B1 if not to much
    trouble to test for you guys.

    DA.

  2. We could also get desired effect if database connection string + table
    prefix will be used instead of FULL_PATH,
    e.g."mysql://user:pass@localhost:inp_".
    This way we won't need to add anything into config.php .

    This way installations, that are using same database on same seever and with
    same table prefix will use same caching key as well.

  3. Nope, it won't work in cases when we have 2+ DB servers (different IPs)
    which is already the case with one of the projects. I wouldn't go this path.

    Let's look at this again - we need to have 2 different copies of the site
    (the same or different servers) working with the same database be able to
    share the same Serial Key for Memory Caching.

    The case you are describing is VERY rare and in most cases would occur in
    the development. I believe we can and should add NEW "SiteMode" (development
    or live) variable to the config which will allow us to resolve described
    issue and in the future refer to this new config value for more for more
    flexibility on if Website is in Production or Development.

    In other words, I say let's go with your initial idea.

    DA.

  4. Solution, used right now won't work for your 2 servers too, since each of
    your servers will have different FULL_PATH :)

    At least my 2nd solution won't break anything or require additional
    knowledge from programmers.

  5. Not sure why you think it won't work - it's the same FULL_PATH and BASE_PATH
    on these servers. The idea is that they are identical.

    DA

  6. I didn't knew that. I'll hope, that developers won'be forgetting to set
    proper mode in future. I will stick to my original idea then.

  7. After some additional research looks like we can use the DB connection
    credentials to build up the KEY Serial as was proposed by Alex.

    Alex would you please create a task and describe what needs to be done
    there.

    Thanks.

    DA.

  8. New task created:

    877: Single Cache Serial-key for Developers on the same Server

    INP-707 - Getting issue details... STATUS


    DA

  9. New issue related to this task/discussion has been found and filed here
    (posted for the future reference):

    Missing "Database Name" in Memory Cache Key<https://groups.google.com/d/topic/in-portal-bugs/1bMaYpQkm2A/discussion>
    .

    DA