Cache example

The new (and experimental) template csaec.mlg provides code to transparently cache your resultsets into a Redis key value store. The generated code relies on the Jedis java client.

Regular service

List<AirportBean> getAirportList(String cityServed) 
<<
    select iata,icao,city_served,region,airport_name 
    from   t_airport 
    where  city_served=?
>>

Same service cached

cache List<AirportBean> getAirportList(String cityServed) 
<<
    select iata,icao,city_served,region,airport_name 
    from   t_airport 
    where  city_served=?
>>

So to cache your service you just need to add the 'cache' statement in front of the method.

What will happen is that the resultset will be stored in binary fashion in the Redis kv store. The key under which this happens is a combination of the 'fully qualified' method name and a concatentation of the parameters.

String cache

This is second variation for the caching code.

scache List<AirportBean> getAirportList(String cityServed) 
<<
    select iata,icao,city_served,region,airport_name 
    from   t_airport 
    where  city_served=?
>>

Notice the 's' (which stands for 'string') in front of the cache keyword. What's different with the binary cache? Instead of using the binary jedis, all data is put as tab-separated strings. This would be usefull for testing (if you want to check in the Redis kv store), or if you want to use it with another redis client.

Have a look at the generated java code for a better understanding.

When you experiment with binary and string cache you'll notice that the binary cache is a lot (really a lot) faster then string cache.

So stick to binary caching, and you'll be quick!

Restrictions apply

• caching is only implemented for methods returning lists like the above
• don't forget to use the csaec.mlg template, otherwise your 'cache' statements will be ignored
• it's experimental at this stage