[jira] Updated: (CAY-1019) Streamlining LOCAL_CACHE handling

From: Andrus Adamchik (JIRA) ("Andrus)
Date: Thu Apr 17 2008 - 14:34:52 EDT

  • Next message: Andrus Adamchik (JIRA): "[jira] Created: (CAY-1035) Replace QueryMetadata String cache policies with an enum"

         [ https://issues.apache.org/cayenne/browse/CAY-1019?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

    Andrus Adamchik updated CAY-1019:
    ---------------------------------

        Description:
    Per CAY-1013 I created a fix for a LOCAL_CACHE refreshing issue. Now trying to look at the bigger picture and address a related problem:

    LOCAL_CACHE and multiple levels of nesting.

    When we have a DataContext connected to the DataDomain, LOCAL_CACHE is what's cached at the DC level, shared - at the DD. If we have an ROP situation (CayenneContext -> DataContext -> DataDomain) or a nested DC situation (DataContext -> [DataContext]+ -> DataDomain), LOCAL_CACHE setting causes caching to occur all the way down to the last DC in a chain... This behavior is clearly wrong. Only the starting DC should cache query results.

      was:
    Per CAY-1013 I created a fix for a LOCAL_CACHE refreshing issue. Now trying to look at the bigger picture and address a few more related problems:

    1. LOCAL_CACHE and multiple levels of nesting.

    When we have a DataContext connected to the DataDomain, LOCAL_CACHE is what's cached at the DC level, shared - at the DD. If we have an ROP situation (CayenneContext -> DataContext -> DataDomain) or a nested DC situation (DataContext -> [DataContext]+ -> DataDomain), LOCAL_CACHE setting causes caching to occur all the way down to the last DC in a chain... This behavior is clearly wrong. Only the starting DC should cache query results.

    2. Sharing LOCAL_CACHE store. Pluggable cache implementation is only good as long as it can be easily managed. Current situation when each DC (or CC) has its own QueryCache instance is the opposite of manageable. On the server-side I am going to use NestedQueryCache as a default strategy for all DataContexts created via DataDomain or a parent DataContext... ROP situation is trickier... There is nothing like a DataDomain (which can be thought of as a specialized IoC container that creates DataContexts based on preconfigured parameters)... It is up to the user to assemble the stack. So we can either leave things the way they are, or start adding DataDomain-like factory functionality to the ClientChannel.

    reducing the scope of this Jira as... he second part related to sharing the query cache via NestedQueryCache has serialization implications, so it is not as straightforward.

    > Streamlining LOCAL_CACHE handling
    > ---------------------------------
    >
    > Key: CAY-1019
    > URL: https://issues.apache.org/cayenne/browse/CAY-1019
    > Project: Cayenne
    > Issue Type: Improvement
    > Components: Cayenne Core Library
    > Affects Versions: 3.0
    > Reporter: Andrus Adamchik
    > Assignee: Andrus Adamchik
    > Fix For: 3.0
    >
    >
    > Per CAY-1013 I created a fix for a LOCAL_CACHE refreshing issue. Now trying to look at the bigger picture and address a related problem:
    > LOCAL_CACHE and multiple levels of nesting.
    > When we have a DataContext connected to the DataDomain, LOCAL_CACHE is what's cached at the DC level, shared - at the DD. If we have an ROP situation (CayenneContext -> DataContext -> DataDomain) or a nested DC situation (DataContext -> [DataContext]+ -> DataDomain), LOCAL_CACHE setting causes caching to occur all the way down to the last DC in a chain... This behavior is clearly wrong. Only the starting DC should cache query results.

    -- 
    This message is automatically generated by JIRA.
    -
    You can reply to this email to add a comment to the issue online.
    



    This archive was generated by hypermail 2.0.0 : Thu Apr 17 2008 - 14:38:07 EDT