You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cayenne.apache.org by "Andrus Adamchik (JIRA)" <de...@cayenne.apache.org> on 2008/03/30 15:39:39 UTC

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

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 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.

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


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

Posted by "Andrus Adamchik (JIRA)" <de...@cayenne.apache.org>.
     [ 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.


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

Posted by "Andrus Adamchik (JIRA)" <de...@cayenne.apache.org>.
     [ https://issues.apache.org/cayenne/browse/CAY-1019?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Andrus Adamchik closed CAY-1019.
--------------------------------

    Resolution: Fixed

> 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.