@Service
@Transactional
public class SomeService {

    public void work() {
        // perform all operations here with
        // transactional semantics
    }
}

Combine the lightweight @Transactional annotation with <tx:annotation-driven mode="aspectj" /> and AspectJ’s load-time weaving and <context:load-time-weaver /> or compile-time weaving (typically in your pom.xml), and you’re done.
I wanted to include something similar in Scalad. The “trouble” is that I did not want to include any dependency on the Spring Framework (though I wanted to be able to use the Scalad code in Spring, if necessary); I wanted to be able to declare that all methods in a class are transactional; and I didn’t want to write unnecessary code.

Scalad.transactionally

The core of the operation is the transactionally method that applies the transactional semantics to some function f:

def transactionally[A](manager: PlatformTransactionManager)(f: => A) = {
  val transaction = manager.getTransaction
  try {
    transaction.begin()
    val ret = f
    transaction.commit()

    ret
  } catch {
    case e: Exception =>
      transaction.rollback()
      throw e
  }
}

That’s the transactional logic and we can use it in our Scala code:

def foo = {
  transactionally(somePlatformTransactionManager) {
    // executes with transactional semantics
    "42"
  }
}

The problem with this code (at least for me) is that it is easy to forget; if I had a class where every method were transactional, then I’d have a lot of repeated code on my hands.

Transactional trait and TransactionalAspect class

A solution to my laziness is the TransactionalAspect, which contains (amongst others) the transactional advice that is applied around applicable methods.

@Aspect
class TransactionalAspect {

  @Pointcut("execution(* *(..))")
  private def anyExecution() {}

  @Around(value = "anyExecution()")
  def transactionally(pjp: ProceedingJoinPoint) = {
    val platformTransactionManager = ???
    Scalad.transactionally(platformTransactionManager) {
      pjp.proceed()
    }
  }

}

This feels almost right: I can intercept methods and apply the transactional semantics to them. But what about the PlatformTransactionManager? Where should I get that object from? In Spring, life was easy: I had a well-known ApplicationContext and I could look up the bean that implements the PlatformTransactionManager interface. In Scalad, there may not be any such ApplicationContext.
Instead, I take a slightly different approach. If I want to apply the transactional semantics to methods in a class, I need to mix-in the Transactions trait; the trait contains a single abstract method getPlatformTransactionManager. This method is implemented in the various concrete data access classes (for example, in JPA), but none of the concrete data access classes mix-in the trait:

class JPA(private val entityManager: EntityManager) {
  require(entityManager != null, "The 'entityManager' must not be null.")

  import Scalad._
  import scalaz._

  def getPlatformTransactionManager =
    new JPAPlatformTransactionManager(entityManager)

  ...

So, you can decide whether you want [automatic] transactions or not:

class Worker(entityManger: EntityManager) extends JPA(entityManager) {
  def work = …
  def somethingElse = …
}

or

class Worker(entityManger: EntityManager) extends JPA(entityManager)
  with Transactions {

  def work = …
  def somethingElse = …
}

The Transactions trait gives me access to the PlatformTransactionManager in the advice:

@Aspect
class TransactionalAspect {

  @Pointcut("execution(* *(..))")
  private def anyExecution() {}

  @Pointcut("this(transactional)")
  private def transactionalTrait(transactional: Transactions) {}

  @Around(value = "anyExecution() && transactionalTrait(transactional)")
  def transactionally(pjp: ProceedingJoinPoint, transactional: Transactions) =
    Scalad.transactionally(transactional.getPlatformTransactionManager) {
      pjp.proceed()
    }

}

The transactionally advice now receives the ProceedingJoinPoint, allowing me to proceed to execute the unadvised target, but also the Transactions trait–the object on which the advised methods are being executed.

Weaving

Weaving is a process where AspectJ modifies the bytecode of the advised methods with the advices: and so, the only time this can happen is when an advised class is being compiled is being loaded into the JVM’s memory. Compile-time weaving is easy to understand: we first compile our code (using any compiler that prodoces Java bytecode) and then we use the AspectJ weaver to modify the already procuded bytecode.
Load-time weaving is sligtly more complex: We need to be able to hijack–instrument–the JVM’s class loading process. We use the Java Agent in the JVM. All we need to do is to set the -javaagent:/path-to/aspectjweaver.jar JVM parameter.
The AspectJ’s Agent will then find all META-INF/aop.xml files and use the information to drive the weaving process. (The same weaving process that is executed during the compile-time weaving.) In Scalad’s code, the aop.xml references the TransactionalAspect:

<!DOCTYPE aspectj PUBLIC
    "-//AspectJ//DTD//EN" "http://www.eclipse.org/aspectj/dtd/aspectj.dtd">

<aspectj>

    <weaver options="-verbose"/>

    <aspects>
        <aspect name="scalad.transaction.TransactionalAspect"/>

        <include within="*"/>
        <exclude within="javax.*"/>
        <exclude within="org.aspectj.*"/>
        <exclude within="scala.*"/>
        <exclude within="scalaz.*"/>
        <exclude within="scalad.*"/>
    </aspects>

</aspectj>

Running

We will run the example application with AspectJ’s load-time weaving. All that is required is to include the -javaagent JVM parameter when running the Main class. You will find the weaver JAR in your Maven repository in ~/.m2/repository/org/aspectj/aspectjweaver/1.6.11/aspectjweaver-1.6.11.jar.

Code

As usual, the code is at https://github.com/janm399/scaladata and more details are at http://www.cakesolutions.org/scalad.html.

long before = System.currentTimeMillis();
doSomeWork();
long elapsed = System.currentTimeMillis() - before;
// check that elapsed < 1

This is not great. It turns out that the operating system’s tick measurement greatly depends on the platform. On the Intel platform, the OS uses the default timer, which ticks 128 times a second. That means that the timer resolution will be roughly 8 ms. Not great. We need something far more accurate.
It turns out that on Intel CPUs (Pentium and above), you can use the RDTSC instruction that returns the number of processor ticks since power-up as 64bit number. “Aha!”, you say, “this is it.” The trouble is that the ticks are relevant only to the CPU on which the code is running. On a multi-processor system, the thread can run on any CPU and the CPUs do not have the same number of ticks. Dang!

OS functions

Your only option is to use the functions of the operating system. On Windows, you can call QueryPerformanceCounter(); on UNIX, you can use gettimeofday(...). These methods will give you roughly microsecond accuracy, which is usable for measuring sub-millisecond code.

Measuring critical code

The catch is that the impact of the measurement code can distort the numbers. The way around it is to calculate the measurement time overhead (per call, using compile- or load-time weaving) and then record the performance and the number of calls. Then you can subtract the expected overhead from the measured value, giving you reasonably accurate number.

AOP

Let me give you head start:

@Aspect
public class PerformanceMonitoringAspect {
    private final long THRESHOLD = 500L;  // 500 ns
    private final long callCount = 0;

    @Pointcut("execution(* net.cakesolutions.citi..handler.*.*(..))")
    private void handlerMethodExecution() { }

    @Around("handlerMethodExecution()")
    public Object performanceCollector(ProceedingJoinPoint pjp) throws Throwable {
        this.callCount++;
        long start = HighPerformanceTimer.getNanoTime();
        try {
            return pjp.proceed();
        } finally {
            long elapsed =
                (HighPerformanceTimer.getNanoTime() - start) -
                callCount * 4; // call time correction
            if (elapsed > THRESHOLD) writePoorPerformanceLogEntry(pjp);
        }
    }

    private void writePoorPerformanceLogEntry(ProceedingJoinPoint pjp) {
        System.out.println("Slow!");
    }
}

If you need any more information, contact me at Cake or come over to the next Spring User Group meeting, bring some purple cauliflower and I’ll talk.