Concurrency Utilities (JSR 166) is a new Java EE standard that comes with the Java EE 7 specification. This standard is about the presentation of Executor API which was introduced with Java 1.5 as container-side and managed objects.

Executor API is located under the High Level Concurrency Objects title in the Java SE documents which are presented by Oracle. Executor API provides Thread management efficiently through the objects it offers. In general, this efficiency is provided by a several of Thread Pool mechanisms. .

Thread Pooling

Thread pools contain creating a specified number of Worker Thread and running of the user-defined tasks with these worker threads. In this way, maximum running user-defined tasks are limited by Pool Size and system resources are being used efficiently.

The figure above can help you understand Thread Pools better. For example on the left side, it is wanted to execute 5000 pieces of tasks on your application with for loop. Trying to activate these 5000 pieces of tasks without using Thread Pool will threaten the system resources. We can understand better this threat issue by looking at the number of tasks (Thread) that a running application in your system activates. .

For example, this one shows a series of processes and a number of Threads that it manages which are executed in my machine. It can be seen clearly that idea.exe application has 71 pieces of threads. When you look at other applications, you can see that less thread is being used. So, if I have 5000 pieces of tasks and fork these 5000 pieces of tasks as 5000 different threads, does it mean that I set up a good architecture? (Of course not : )

If, in fact, I make run the tasks by making choices (random or priority) from these 5000 tasks with the specified number of Worker Threads, I use the system resources efficiently and do not put the system in an unnecessary stress. Because 5 pieces of Worker Thread is defined in the above chart, the effect of these tasks to the system it runs will be seen at most 5 user-defined tasks. When a worker thread finishes, one of the currently waiting task will be selected and this running process will continue until all tasks finish. So, the basic philosophy of Executor API that comes with Java SE 1.5 is to provide efficient Thread management by offering a variety of thread pool environments. Worker threads are the common type of threads that are generated by thread factory.

The basic interface types within the Executor API are ExecutorService and ScheduledExecutorService. The implementation of these interfaces may be a various of static methods of Executors class.

The new Concurrency Utilities Standard that comes with Java EE 7 makes these object types injectable and manageable by container services. However, container managed executor objects appear with the names of ManagedExecutorService and ManagedScheduledExecutorService in terms of representing the manageability. When you look at the UML diagrams of these interfaces, it can be seen that Java SE Executor API interfaces are extended .

Interfaces which start with managed basically provide the same operations that the Executor API components provide which comes with Java 1.5. The difference here is to present the new objects as container resources to the developers.

Container resources are special objects that are managed by application servers. DataSources, JMS resources and the Concurrency units with the Concurrency Utilities standard are the examples of container resources.

Container resources are the objects that reside on application server and they perform specific functions. The access to these objects can be established by JNDI (Java Naming and Directory Interfaces) standard. This access operation can be achieved basically through the @Resource annotation or the Context interface type objects (e.g. InitialContext).

Creating Concurrency Resources

Manageable executor objects within the Concurrency Utilities can be created on application servers which supports Java EE 7 specification. For example, this creating process can be defined visually through the asadmin command set for Glassfish 4 or over the Glassfish Admin Console.

The asadmin tool in the /bin directory of Glassfish application server is being used for command line operations. In the following example, the asadmin tool is run and manageable executor objects are created interactively with create-managed-executor-service or create-managed-scheduled-executor-service commands. Because the container resources are provided to application environments with the access expressions which were defined in JNDI standard, the unique access identifier which represents that container resource should be entered to console.

These created manageable executor objects can be seen through the Glassfish Admin Console. Similarly, these adding and editing operations can be done through the admin console .

Container resources on Glassfish 4 appear under the Resources tab. Concurrent resources appear under a sub-tab, Concurrent Resources. While ManagedExecutorService and ScheduledManagedExecutorService resources that we created it as manageable by container are found in this part, Concurrency resources with __default prefix which were defined immanently on application server are also available. If desired, existing default resources can also be used.

Getting Resources of Concurrency Utilities

Concurrency resources that reside on application server can be obtained through @Resource annotation with injection or through the InitialContext objects. The @Resource annotation and InitialContext object provide standard JNDI access not only to Concurrency resources, but also to all other container resources.

@WebServlet(urlPatterns = "/kodcu",name = "KodcuServlet")
public class KodcuServlet extends HttpServlet {

@Resource // (1)
private ManagedExecutorService defaultmanagedExecutorService;

@Resource // (2)
private ManagedScheduledExecutorService defaultScheduledExecutorService;

@Resource(lookup = "concurrent/KodcuExecutor") // (3)
private ManagedExecutorService managedExecutorService;

@Resource(lookup = "concurrent/KodcuScheduledExecutor") // (4)
private ManagedScheduledExecutorService scheduledExecutorService;

@Override
protected void doGet(HttpServletRequest req, HttpServletResponse resp) throws ServletException, IOException {

...

InitialContext context=new InitialContext(); // (5)

ManagedExecutorService managedExecutorServiceWithContext = (ManagedExecutorService) context.lookup("concurrent/KodcuExecutor");

...

}

}

In the above Servlet class, the default Concurrency resources (number 1 and 2) and the resources which were created by specifying JNDI name in the command line (number 3 and 4) are being obtain through @Resource annotation with resource injection. The lookup field of @Resource annotation gets the relevant object of unique resource access identifier which was defined with JNDI standard. When @Resource annotation is used without lookup attribute, JNDI resources with __default prefix are being injected. In section 5, except injection method, Concurrency resource is obtained according to relevant JNDI name through the InitialContext object.

You can access to example in the following link

http://en.kodcu.com/2013/10/java-ee-7-concurrency-utilities-spesification/

By for now.