Service layer

All individual business operation must be placed into a service. One method call per business functionality.

A service is the unit of work. It have both logical and transactional boundaries.

Typical Service configuration

        @Service
        @Transactional(rollbackFor = { Exception.class })
        public class SessionService implements ISessionService {
          private final static Logger log = LoggerFactory.getLogger(SessionService.class);
          @Autowired
          private ISessionDao sessionDao;
        ...

Autowire first

There are multiple way of wiring spring beans together:

• xml: good old spring config
• java: as a replacement of spring xml files. Serious advantages is that type safe. no need to startup Spring application to ensure that config contains no misspelled class names (as an example).
• annotation: 90% of the cases an interface has only 1 implementation. In such a cases it is more effective to use annotation based dependency injection.

You must declare where to search for annotated classes in spring.xml:

        <context:component-scan base-package="ep.pericles.dao" />

You could declare implementations to be spring managed in spring xml or using annotation.

This will be only a plain bean:

        @Component
        public class AssignmentResponseErrWarnFormatter extends ReflectiveVisitor {

or Dao:

        @Repository(value = "PliSessionDao")
        public class PliSessionDao extends SessionDao implements IPliSessionDao {

or Service:

        @Service
        @Transactional
        public class SessionService implements ISessionService {

For wiring automatically you can use @Autowire

         @Autowired
          private ISessionDao sessionDao;
          @Autowired
          private ISessionFinder sessionFinder;
          @Autowired
          private IInterpreterService interpreterService;

For more detail read spring manual.

Separate finder service from operations

You could qualify service into two categories: finder and operation.

Operations must have a strict declared transaction management around it.

Finder service are providing readonly functionalities. No transaction management expected to be effect on these services.

        @Service
        @Transactional(readOnly = true)
        public class SessionFinder implements ISessionFinder {
        ...

Cache

Most of the time it is enough to use declerative cache what Spring(3.1) provides ou of the box.

Declaration is not an issue and has no effect on the code at all:

  @Cacheable("i18n")
  public String text(String code, String lang_iso_code) { ...

in the spring xml:

         <bean id="cacheManager" class="org.springframework.cache.support.SimpleCacheManager">
                 <property name="caches">
                         <set>
                                 <bean class="org.springframework.cache.concurrent.ConcurrentMapCacheFactoryBean" p:name="default" />
                                 <bean class="org.springframework.cache.concurrent.ConcurrentMapCacheFactoryBean" p:name="UnavReason" />
                                 ...
                         </set>
                 </property>
         </bean>

This XML confign is the simplest solution (mainly for prototype or testing purposes) In production ready code you should use EHcache or something else.

This annotation can be applied to both dao and service level.

Cache problem - not caching when internal method is called

This cache is easy to use and easy to missuse. Bu the problem is not about the cache but how Spring handling proxied bean insances.

You might notice that the method call is not cached even if it has the annotation on it. Typical case when the annotated method is called internally. Example:

  @Cacheable(value = "Interpreter")
  public Map<Long, InterpreterDto> getAllInterpretersMap(List<Long> ids) {
  ...
  //within he same class
  ...
  Object x = this.getAllInterpretersMap(asList(1,2,3));

In this case the @Cacheable annotation is not applied because the cache is build around the instance not inside.

Solution?

1. Refactor you code to have external access to that method
2. use explicite cache
3. Resolve in an other way

Cache problem - not caching even if I call externally

The origin of the problem can be related to the default KeyGenerator implementation. It does not support:

• collection, array, custom bean (other than primitive): it extensively usign hashcode and equals method. So custom types should override these methods but but onfortunatelly when using collection you might not able to do that. For example you could not override array hashcode function.
• variable length arguments like String... arg: each time you call such a method a new array object is created and array objects are not supported

Home made KeyGenerator

Solution: use your own implemenation.

 public class AppKeyGenerator implements KeyGenerator {
   private static Logger log = LoggerFactory.getLogger(AppKeyGenerator.class);
 
   @Override
   public Object generate(Object target, Method method, Object... params) {
     Class<?> objectclass = AopProxyUtils.ultimateTargetClass(target);
     List<Object> cacheKey = new ArrayList<Object>();
     cacheKey.add(objectclass.getName().intern());
     cacheKey.add(System.identityHashCode(target));
    cacheKey.add(method.toString().intern());
    ImmutableList.Builder<Object> paramBuilder = new ImmutableList.Builder<Object>();
    buildFlattenParamList(paramBuilder, params);
    List<Object> flattenParamList = paramBuilder.build();
    cacheKey.addAll(flattenParamList);
    log.trace("{}", cacheKey);
    return cacheKey;
  }

  private void buildFlattenParamList(Builder<Object> paramBuilder, Object[] params) {
    for (Object p : params) {
      if (p instanceof Object[]) {
        buildFlattenParamList(paramBuilder, (Object[]) p);
      }
      else {
        paramBuilder.add(p);
      }
    }
  }
}

And add to spring xml:

        <cache:annotation-driven key-generator="app_key_generator" />
        <bean id="app_key_generator" class="ep.pericles.cache.AppKeyGenerator" />

Use the KEY

Not so lazy solution.

See 27.3.1.2 Custom Key Generation Declaration

Warning: SPEL might have serious perfomance concequences.

• Physical software project structure
• Service layer
• Data access layer
• Spring MVC
• Web view
• Toolbox
• Testing
• Jawr, webjars, bootstrap, Spring setup trick
• Jakarta Equivalence Relation
• Difficult to test example refactoring