Please post these type of discussions directly to the OPENJPA-1532 JIRA so that we have the history where it's needed.
I have already voiced my view in the JIRA -- the JPA 2 configuration <shared-cache-mode> should direct our internal property settings. Much like we did with the javax.persistence.* properties for the datasource. We didn't tell users to re-define their requests via the openjpa.Connection* properties. Sure, we have some "merging" conflicts to detect and report and act on, but these are not insurmountable. I've had several discussions with customers that ask why <shared-cache-mode> doesn't enable the data cache. Unless someone can show in the spec where this should not control the cache, I'm in favor of having it control our datacache support. I think section 3.7.1 is pretty clear on the intent of enablement or disablement of the cache based on this property. Kevin On Fri, Sep 21, 2012 at 2:29 PM, Rick Curtis <[email protected]> wrote: > > It would lead to complications. > What other complications are you concerned with? > > I don't like the fact that to use the JPA2 way of caching requires two > properties to enable caching. > > On Thu, Sep 20, 2012 at 7:23 PM, Pinaki Poddar <[email protected]> wrote: > > > Rick, > > Having one configuration impacting another is not recommendable. It > would > > lead to complications. > > I am not arguing about rationale of active DataCache for > > <shared-data-cache> > > -- but would refrain to do it *automatically* in code. > > At code level, better would be to simply warn > > "you have <shared-cache> but your data cache is not active. This > directive > > will be ignored unless you ..." > > > > The issue should be handled at documentation level: "if you are using > > <shared-data-cache>, you *must* activate data cache by > > openjpa.DataCache=true etc.". > > > > > > > > > > > > > > > > ----- > > Pinaki Poddar > > Chair, Apache OpenJPA Project > > > > -- > *Rick Curtis* >
