Java Concurrency: Fair Lock

When use synchronized, the order of threads acquire a lock is not same as the order of threads request to acquire a lock.  If you want to have a fair lock mechanism, you should use Java 5 Lock.

java.util.concurrent.locks.ReentrantLock has a constructor with a boolean parameter. With this constructor, you can have fair lock mechanism.  ReentrantLock has a queue to contain threads which want to acquire this lock.  When a thread releases this lock, then the header will acquire this lock if the queue is not empty.

Use jOOQ to mock JDBC

When you want to do unit tests for the DB access layer of a project, you may need to mock JDBC API.  But it will be an awkward work if you do it with common Mock frameworks like JMock or Mockito.  At that moment, you can consider use jOOQ to do that.

jOOQ is a Java framework to help you to write type-safe SQL DML (there is a similar framework named QueryDSL.  But it is more powerful than jOOQ).  And it shipped with a JDBC mock class collection.  With these classes, you can mock JDBC API for your DB layer UT.

You can view the reference of jOOQ for details: JDBC mocking for unit testing.

SIP Servlet 2.0 POJOs

Recently I talked with SIP Servlet expert group member George Vagenas from TeleStax about how to route SIP message with annotation (The thread link).  He mentioned that there will be a great feature in SIP Servlet 2.0, which called SIP Servlet 2.0 POJOs.  This feature will provide some annotations.  With these annotations, you can write your SIP application with POJOs in SIP Servlet 2.0 container. One of my most favorite annotations is @SipPredicate.  With this annotation, you can route SIP message to your expected method.

The example of this annotation is following:

With this annotation, SIP Servlet container can know that whether a SIP message should be processed by the method with this annotation or not.

The link of the draft of SIP Servlet 2.0 POJOs: http://java.net/projects/sipservlet-spec/lists/jsr359-experts/archive/2013-02/message/41

MMIM MSRP EOF Exception

Recently, in the project MMIM, the TCP layer of MSRP module often threw an IOException (EOF Exception).  In the exception trace stack, there is without any our code, so it was not easy to find the cause.  But because this exception did not happen before, so I still believe this exception was caused by our code or something else.  One of most possible reason to cause IOException is the connection broken, and there are two kinds of connection broken, the server side broken and the client side broken.  So I tested this two scenarios, then found that if the server side to broke the connection, there is no exception, but the client to broke the connection will cause that exception.  Then I checked the client side.  Finally, I found it caused by the Tcl script to terminate MSRP Client before SIP layer sent BYE to terminate the MSRP session.

Template Method pattern in Java - Two Ways

In Java, there are two ways to implement Template Method pattern.  One is to use abstract method, another is to use anonymous inner class.  In the first way, you need to write an abstract base class.  In this abstract class, you should have at least one main public method.  This method is the main entry of your class and implement the main function.  At the same time, in this abstract class, you should add some abstract methods invoked by the main public method to make sub-classes to implement the details.

The second way is not the typical Template Method pattern.  But it can achieve the similar goal.  You can find a lot of examples from open source projects to use anonymous inner class to implement Template Method pattern.  One of famous examples is JdbcTemplate from Spring JDBC project.  In this class, the methods like execute(ConnectionCallback action) are using inner class to implement a template method.  The benefit using anonymous inner class to implement Template Method pattern is that you do not need to extends a base class.  So it is more flexible than the abstract class way.  But the con is you cannot enjoy the polymorphic type.

Java Concurrency: Thread State

In Java, a thread has 5 kinds of states: NEW, RUNNABLE, BLOCKED, WAITING, TIMED_WAITING, TERMINATED. When you execute Thread.sleep(long), the current thread status will transform from RUNNABLE to TIMED_WAITING, and the current thread will give up CPU resources to another threads. But the current thread will not give up the monitor.

When execute Object.wait(), the current thread will become to WAITING state ( Object timed wait will make thread to TIMED_WAITING state ). But different with Thread.sleep(), Object.wait() will make thread to give up the monitor.

When your code use synchronized keyword try to acquire a monitor but blocked, the current thread will be at BLOCKED state. At that moment, the thread cannot respond to the interruption. But at WAITING and TIMED_WAITING state, a thread can have chance to respond to the interruption.

Different with synchronized, Lock.tryLock(long time, TimeUnit unit) can respond to the interruption. So use Lock in Java 5 concurrent is a way to avoid dead lock.