Refactor Concurrency Control To Aspect

CategoryRefactoring /RefactoringLanguage - an instance of AspectOrientedRefactoring

See "Extract concurrency control" for an example of extracting read and write locks, with corresponding try-catch-finally blocks, into using AspectOrientedProgramming techniques.

• http://www.theserverside.com/articles/article.tss?l=AspectOrientedRefactoringPart2

From this:

public <type> <methodName>(<parameters>) {
try {
_lock.writeLock().acquire();
< business logic here > 
} catch (InterruptedException ex) {
throw new InterruptedRuntimeException?(ex);
} finally {
_lock.writeLock().release();
}
}

To this:

public <type> <methodName>(<parameters>) {
< business logic here > 
}

and a pointcut to define which methods need which kinds of locks, and reusable definitions of how to aquire and release locks:

before() : writeOperations() {
_lock.writeLock().acquire();
}
after() : writeOperations() {
_lock.writeLock().release();
}

For Java/AspectJ definitions not in-line in the article, see:

• 'http://www.theserverside.com/articles/content/AspectOrientedRefactoringPart2/ReadWriteLockSynchronizationAspect.java.html'

---

The first code is bad, admittedly, but in any normal program the concurrency control would be implemented via delegation, as a decorator or via message queues. How does aspect orientation help in that situation? The only effects I see are negative (hidden dependencies, for example).

Also, where is _lock defined in the AspectJ version?

Generally aspects inject the lock object into the business object (inter-type field declaration) without polluting namespace of the business logic or other aspects, like this:

private final Lock BusinessLogicClass?._lock=new ReentrantLock?();

---

CategoryRefactoring