• Home
KodEduKodEdu
  • Home

Java EE 7 – Concurrency Utilities

  • Posted by Rahman Usta
  • Categories Genel, Uncategorized, Yazılar
  • Date 23 October 2013

Concurrency Utilities (JSR 236) 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.

thread-pool

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. .

task-manager

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.

thread-pool-N

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 .

uml-concurrency-objects

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.

asadmin-concurrency-utilities

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 .

glassfish-admin-console-concurrrent-utilities

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 sample application from this link https://github.com/rahmanusta/ConcurrencyUtilities-N.

Bye for now.

Tag:backend, concurrency, injection, javaee, javaee7

  • Share:
author avatar
Rahman Usta
Java Champion, Java* Trainer and Author. JCP Expert, Istanbul JUG and Adopt a JSR member. Duke's Choice Award 2015 winner. Ex-Voxxed Istanbul Organizer. Creator of AsciidocFX.

Previous post

Combine JaxRS 2.0 Rest Client, Java FX 2, Spring MVC and Hibernate
23 October 2013

Next post

HTML 5 Server Sent Events on Glassfish 4
27 November 2013

You may also like

collector
Distributed Map-Reduce Model using Java 8 and Java EE 7 WebSocket
16 November, 2014
server-sent-events-jax-rs-2
HTML 5 Server Sent Events on Glassfish 4
27 November, 2013
mvc-rest-jaxrs-hnate
Combine JaxRS 2.0 Rest Client, Java FX 2, Spring MVC and Hibernate
15 August, 2013

Leave A Reply Cancel reply

Your email address will not be published. Required fields are marked *

  • TürkçeTürkçe

Gözde yazılar

CDI – @Default and @Inject Annotations
14Jun2013
Java API for JSON Processing – Creating JSON Objects
15Jun2013
Jax-RS 2 and LongPolling based Chat Application
25Jun2013
Java API for JSON Processing – Reading and Writing JSON objects
23Jul2013

Recent Posts

  • First look at HTTP/2 Server Push in Java Servlet 4.0 Specification 26 April 2017
  • Distributed Map-Reduce Model using Java 8 and Java EE 7 WebSocket 16 November 2014
  • HTML 5 Server Sent Events on Glassfish 4 27 November 2013
  • Java EE 7 – Concurrency Utilities 23 October 2013
  • Combine JaxRS 2.0 Rest Client, Java FX 2, Spring MVC and Hibernate 15 August 2013

Get Java Software

React.js Eğitimi Başlıyor
11-22 Eylül, 2017
Eğitmen
Rahman Usta
İletişim

merhaba@kodedu.com

  • Hakkında
  • Gizlilik Politikası
  • İletişim
  • Referanslar
Kodedu Bilişim Danışmanlık
Cemil Meriç mah. Çelebi sok.
No:16/3 Ümraniye/İSTANBUL
Tel: 0850 885 38 65
Alemdağ V.D.: 8960484815

KODEDU © Tüm hakları saklıdır.