Grouper Users - Open Discussion List

[Chris Hyzer <>]

Right, that too… the case would be if an app were making the same query over and over and wasn’t caching on the client, and doesn’t need immediate updates as you say

 

Thanks,

Chris

 

From: Doppala, Karthik [mailto:]
Sent: Tuesday, October 01, 2013 2:17 PM
To: Chris Hyzer
Cc:
Subject: RE: Grouper web service caching

 

Thanks Chris!

We do not see a use case for caching in grouper-ws as any changes made from ui would not reflect immediately through the web service.

 

From: Chris Hyzer []
Sent: Monday, September 30, 2013 6:18 PM
To: Doppala, Karthik
Cc:
Subject: RE: Grouper web service caching

 

The caching in Grouper needs more documentation and tuning around use cases.  Also, we could put high level caches in the WS as you suggest.  The key would be the input to the WS, and the authenticated user, and the output is whatever the output is.  Then if you want to cache hasMember, or whatever, you could do that pretty easily.

 

Right now most of the hibernate methods do have caches.  getMember WS calls Hib3MembershipDAO.findAllByGroupOwnerAndMemberAndField() which has this:

 

    Set<Object[]> mships = HibernateSession.byHqlStatic()

      .createQuery(sql.toString())

      .setCacheable(true)

      .setCacheRegion(KLASS)

      .setString( "owner",  ownerGroupId              )

      .setString( "member", memberUUID             )

      .setString( "fuuid",  f.getUuid()            )

      .listSet(Object[].class);

 

And the KLASS in this case is: edu.internet2.middleware.grouper.internal.dao.hib3.Hib3MembershipDAO

 

So in the ehcache file, if you set this:

 

  <cache  name="edu.internet2.middleware.grouper.internal.dao.hib3.Hib3MembershipDAO"

          maxElementsInMemory="10000"

          eternal="false"

          timeToIdleSeconds="60"

          timeToLiveSeconds="60"

          overflowToDisk="false"

          statistics="false" 

  />

 

Then the hasMember will essentially be set for 1 minute.  I say essentially because there might be group lookups or other queries going on (privileges?)  I don’t know until I profile that call.  But there could be other side effects like that method in the API might be used by other things that make things work.  Like an operation that makes an update and reads it, and expects it not to be cached, it could be broken.

 

Anyways, like I said, a more useful WS caching strategy would cache the operation at a higher level, and might even let the caller have input.  i.e. you could cache hasMember for 1 minute by default, but some callers might want 10 minute caching, and some might want no caching…

 

Well, at this point, people might as well chime in as to what caching they would like to see and we can see what we can do.

 

At Penn we cache on the client side so we haven’t really needed server side caching, but if you think that is not convenient or for whatever reason let us know J

 

Thanks,

Chris

 

 

 

From: Doppala, Karthik []
Sent: Monday, September 30, 2013 8:54 PM
To: Chris Hyzer
Cc:
Subject: Grouper web service caching

 

Hi Chris,

I was wondering if grouper-ws uses caching internally, I do see that it does have ehcache configured but the ehcache.xml file is not really referenced in the grouper.hibernate.properties file. If it does, where does it cache ? Your response is appreciated

 

Thanks,

Karthik