The Thread Tracker Pattern

Basically, this pattern helps to analyze problems and errors by clearly defining the name for the current thread because sometimes we are in multithreaded environment and it is very difficult to know who caused the error.

Adam Bien posted his Thread Tracker Pattern. This page is an adoption of his work. Changing the name of the current thread is not explicitly allowed by the JEE specification, but it is also not forbidden. Changing the name of the current thread is an example of either a ServletFilter, an EJB Interceptor or an AOP(AspectJ) aspect. Using one of those technologies can save a lot of time.

 

import javax.interceptor.AroundInvoke;
import javax.interceptor.Interceptor;
import javax.interceptor.InvocationContext;
import java.lang.reflect.Method;

@Interceptor
@ThreadTracking
public class ThreadTracker {

@AroundInvoke
public Object handleInvocation(InvocationContext aContext) throws Exception {
Method theMethod = aContext.getMethod();
String theCurrentThreadName = Thread.currentThread().getName();
try {
Thread.currentThread().setName(theMethod.getDeclaringClass().getSimpleName() + “.” + theMethod.getName());
return aContext.proceed();
} finally {
Thread.currentThread().setName(theCurrentThreadName);
}
}
}

 

 

 

Basics types of relationship Objects

 

ClassDiagramRelationship

Association is a relationship where all objects have their own lifecycle and there is no owner. Let’s take an example of Teacher and Student. Multiple students can associate with single teacher and single student can associate with multiple teachers, but there is no ownership between the objects and both have their own lifecycle. Both can create and delete independently. In Association with can have  one-to-one, one-to-many, many-to-one, many-to-many sub-types of relationships. Persistence framework Hibernate in ORM use that.

Aggregation is a specialised form of Association where all objects have their own lifecycle, but there is ownership and child objects can not belong to another parent object. Let’s take an example of Department and teacher. A single teacher can not belong to multiple departments, but if we delete the department teacher object will not be destroyed. We can think about it as a “has-a” relationship.

Composition is again specialised form of Aggregation and we can call this as a “death” relationship. It is a strong type of Aggregation. Child object does not have its lifecycle and if parent object is deleted, all child objects will also be deleted. Let’s take again an example of relationship between House and Rooms. House can contain multiple rooms – there is no independent life of room and any room can not belong to two different houses. If we delete the house – room will automatically be deleted. Let’s take another example relationship between Questions and Options. Single questions can have multiple options and option can not belong to multiple questions. If we delete questions options will automatically be deleted.

Generalization uses a “is-a” relationship from a specialization to the generalization class. Common structure and behaviour are used from the specializtion to the generalized class. At a very broader level you can understand this as inheritance. Why I take the term inheritance is, you can relate this term very well. Generalization is also called a “Is-a” relationship.

Realization is a relationship between the blueprint class and the object containing its respective implementation level details. This object is said to realize the blueprint class. In other words, you can understand this as the relationship between the interface and the implementing class.

Dependency: with a change in structure or behaviour of a class affects the other related class, then there is a dependency between those two classes. It need not be the same vice-versa. When one class contains the other class it this happens.

 

Thanks Varun Gupta and Ajay from stackoverflow.com