Caching strategies

Hi folks,

I’ve been digging into the ColdBox caching features lately and wanted to see if I’m on the right track for my approach. I am referencing:

The app i’m building is a REST API. The apps which consume the API periodically poll a handful of endpoints to refresh their data - i.e getUser (returns JSON user object), getLocations (returns JSON locations list). For the most part the data returned from these enpoints doesn’t change that often. The only one that would be most likely to change is the UserObject.

For the getUser request my handler makes a request to UserService, which loads the data through ORM then returns back a struct. My postHandler then converts and returns the data using event.renderData.

I’m thinking about implementing caching in my userService to first check the cache to see if the cached object exists…if it does return it, else load the data via ORM, then cache it.

//user service

function getUser(userid){

var oMD = structnew();
var user = 'user_' & arguments.userid;
  if ( getColdboxOCM().lookup(user) ){
    oMD = getColdboxOCM().get(user);

	var getUser = EntityLoadByPK('User',arguments.userid);
	///create struct
	var userStruct = {}, etc...
	//place struct into cache


This my first time working with ColdboxOCM. Is the above a valid approach for using this feature and caching on a user by user basis? Obviously I would need to build in a feature on say a userUpdate endpoint which would do the same lookup, expire the key, and the reset after update.

Thanks all.

You ate looking at the old docs for 2.6. Go to wiki.coldbox.Org

Within the next two weeks (or so) I’ll be blogging on how I implemented an API in ColdBox and will include my caching strategy.

I implemented caching in the following areas:

  • Cache at Hibernate using the secondary cache
  • Cache the mementos I constructed for each object (important for me since not everything in the objects are public)
  • Cache the serialized JSON response using cleaned/organized key based on provided params.
    This API lives within the main application so an interceptor is used to break the interceptor chain for API requests pretty high in the interceptor stack as well to avoid unnecessary processing.

My response times can be as high as 7 seconds for large collections without caching, however, most public visitors have a response within 30ms due to the caching and a constructor process that takes the big hit during app init while servers are out of the load balancer.


Thanks Aaron. Looking forward to reading your post!

Nolan Dubeau

Load .,8,1