Grouper Users - Open Discussion List

["Michael R. Gettes" <>]

i believe caching of subject source data is reasonable for all interfaces to grouper.  Caching for 10-60 minutes is appropriate (of course, your mileage may vary).  We have tried to implement changes along these lines but apparently there is a fine art to this.  Some examples of how to achieve subject source caching along these lines as an example I think would be helpful.

I'd also like to think caching for bulk sync and such would be helpful.  As you note, allowing the caller to influence the caching might be useful.  So when bulk sync fires up and hits a group with a large membership, then that large membership may be slow but further memberships would be very fast since they would now be cached for the life of the bulk sync.  Obviously, subject source caching will help here but what else would aid in bulk sync running very fast I am not sure.

I hope this helps.

/mrg

On Sep 30, 2013, at 9:18 PM, Chris Hyzer <>

 wrote:

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 [mailto:kdoppala@it.ucla.edu] 
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