Multi-tenancy issue when CDA resources are shared between users

[webdetails]

Multi-tenancy issue when CDA resources are shared between users

[pamval]

Why is CDA settings sharing by other users a problem?
AFAIK, this caches only the metadata for the connections/queries. Can you share a use case for this ?

The changes you made result in a segregated cda settings cache per user, which is something we'd like to avoid.

[spektom]

Suppose I have a CDA resource shared between all the users. In its DataAccess sections, I have a proper caching key definition:

<Cache enabled="true" duration="900">
  <Key name="user-in-session" value="${[security:principalName]}" default="user-in-session"/>
</Cache>

When looking at the same report from two different users (which use different data sources) I see the same data. Why is that? This is because the settings of this CDA were inserted into a cache when the first user has opened the report, and the cache key has gotten the value: user-in-session:firstUser. When the second user opens the same report its cache key gets user-in-session:firstUser as well, since the settings are cached.

[pamval]

In my opinion, that means we're wrongly pre-calculating the cache keys and keeping that result. The cache key should be calculated when adding the resultset to cache in order to take into account the current context (session vars). Like we do for query parameters, which are also used in building the cache key.

[spektom]

What if we move FormulaEvaluator.replaceFormula() from pt.webdetails.cda.cache.DataAccessCacheElementParser.buildKeyValuePair(Element) to some place like pt.webdetails.cda.dataaccess.AbstractDataAccess.getExtraCacheKey(), so it will be called each time cache key is needed?

[pamval]

I think I'd rather defer the call to DataAccessCacheElementParser.getCacheKey.

Instead of having that being called in the DataAccess constructor, I'd call it in the getCacheKey method. So, everytime a cache key is requested, the right cache key will be computed.
Probably move the parser from being a locally defined variable to object attribute.

[spektom]

Please review the fix!

[pamval]

looks good, merging.

thanks!

[spektom]

Will this fix be merged into 5.1 branch?

[pamval]

The cda 5.1 branch ? No, it won't. Why do you need that ?

[spektom]

I'm asking because we used to take CDA from there (we're using Pentaho
5.1): http://ci.pentaho.com/view/x5.1x/job/pentaho-cda-pentaho-5.1/
If the change will not appear there, then we should take the artifact from
some other place (or build it ourselves).

On Tue, Aug 12, 2014 at 5:23 PM, Pedro Vale [email protected]
wrote:

The cda 5.1 branch ? No, it won't. Why do you need that ?

—
Reply to this email directly or view it on GitHub
#67 (comment).

[pamval]

ok, fair enough.

The trunk builds support Pentaho 5.1 as well, so you can download the trunk build:

http://ci.pentaho.com/job/pentaho-cda/

or the stable builds (although it will be a month or so before this fix gets into the release branch);

http://ci.pentaho.com/job/pentaho-cda-release/lastSuccessfulBuild/artifact/cda-pentaho5/dist/

Pedro Vale
Webdetails Dev Lead

http://www.webdetails.pt

A 12/08/2014, às 15:28, Michael Spector [email protected] escreveu:

I'm asking because we used to take CDA from there (we're using Pentaho
5.1): http://ci.pentaho.com/view/x5.1x/job/pentaho-cda-pentaho-5.1/
If the change will not appear there, then we should take the artifact from
some other place (or build it ourselves).

On Tue, Aug 12, 2014 at 5:23 PM, Pedro Vale [email protected]
wrote:

The cda 5.1 branch ? No, it won't. Why do you need that ?

—
Reply to this email directly or view it on GitHub
#67 (comment).

—
Reply to this email directly or view it on GitHub.