DZone
Thanks for visiting DZone today,
Edit Profile
  • Manage Email Subscriptions
  • How to Post to DZone
  • Article Submission Guidelines
Sign Out View Profile
  • Post an Article
  • Manage My Drafts
Over 2 million developers have joined DZone.
Log In / Join
Refcards Trend Reports Events Over 2 million developers have joined DZone. Join Today! Thanks for visiting DZone today,
Edit Profile Manage Email Subscriptions Moderation Admin Console How to Post to DZone Article Submission Guidelines
View Profile
Sign Out
Refcards
Trend Reports
Events
Zones
Culture and Methodologies Agile Career Development Methodologies Team Management
Data Engineering AI/ML Big Data Data Databases IoT
Software Design and Architecture Cloud Architecture Containers Integration Microservices Performance Security
Coding Frameworks Java JavaScript Languages Tools
Testing, Deployment, and Maintenance Deployment DevOps and CI/CD Maintenance Monitoring and Observability Testing, Tools, and Frameworks
Culture and Methodologies
Agile Career Development Methodologies Team Management
Data Engineering
AI/ML Big Data Data Databases IoT
Software Design and Architecture
Cloud Architecture Containers Integration Microservices Performance Security
Coding
Frameworks Java JavaScript Languages Tools
Testing, Deployment, and Maintenance
Deployment DevOps and CI/CD Maintenance Monitoring and Observability Testing, Tools, and Frameworks
  1. DZone
  2. Coding
  3. Java
  4. Modern concurrency and Java EE

Modern concurrency and Java EE

Sander Mak user avatar by
Sander Mak
·
Nov. 27, 12 · Interview
Like (1)
Save
Tweet
Share
25.02K Views

Join the DZone community and get the full member experience.

Join For Free

managing your own threads within a java ee container is not recommended and even illegal in some circumstances. but where does that leave us when we want to use the shiny new java concurrency frameworks like fork/join and akka in java ee applications? the addition of new concurrency facilities to the java ee 7 spec may open some doors.

the past year i’ve been diving into new concurrency options on the jvm. java se 7 brought us fork/join concurrency, and other other approaches like actor-based concurrency with for example akka gain popularity as well. i did some talks about fork/join (talk on parleys , slides ) and akka (talk on parleys , slides ) and one question i always get is: ‘can this be used in a java ee applications?’

since both fork/join and akka start and stop their own thread(pool)s, the answer is: ‘it usually works, but it is not recommended within java ee containers’. unsatisfactory answer? you bet. but fortunately things may change with the next release of java ee.

jsr-236: concurrency utilities for the java ee platform

most application servers already offer the possibility to get a managed (sort-of, kind-of) threadpool through the workmanager api. it was never standardized as part of java ee though. and even if it was, it would not be enough for the fork/join framework. the only pluggability you get when instantiating a forkjoinpool is a custom thread factory. for the record, it seems that akka can be configured with workmanagers.

however, standardization of application-facing, container-managed threading may be upon us. work on jsr-236 commenced in 2003. yes, that’s almost a decade ago. the first draft of the concurrency ee spec appeared in 2006, but unfortunately it languished ever since. in april of this year, however, the jsr was resuscitated and an updated version was published last month. even though the delta with the 2006 draft is minimal (e.g. ‘update package name from javax.util.concurrent to javax.enterprise.concurrent’), it is good to see things are back on the agenda.

javax.enterprise.concurrent

so what’s in this elusive new javax.enterprise.concurrent package? i salvaged the following diagram from a 2006 javaone presentation , with the new concurrency facilities marked yellow:

java ee concurrency

the two most important interfaces for enabling alternative concurrency frameworks are managedexecutorservice and managedthreadfactory , both extending their non-managed java.util.concurrent counterparts from java se. what does this managed prefix buy us? it means that tasks submitted and threads created through these interfaces will be fully aware of the java ee contextual services. things like transaction management, security context and so on are all available when the task is executed or the thread is used. the container is fully aware of the lifecycle of these managed threads, and can offer generic monitoring and tuning options.

another interesting aspect of the propesed managedexecutorservice is that it must support distribution. one of the following properties can be configured:

  • local: the task is run in the same process/server that submitted the task.
  • distributable: the task may be run in any process/server including the one that submitted the task.
  • distributable with affinity: the task may be run in any process/server including the one that submitted the task. all tasks will then run on the selected process/server.

suddenly we have the building blocks for an asynchronous, distributed computation engine at our fingertips! obviously, the tasks need to be serializable for this to work.

connecting the dots

you might be wondering why it is important to have these concurrency utilities, since java ee 6 already provides the @asynchronous annotation on ejb’s and async servlet support is also available. however useful these are for application development, the constructs are not meant to bootstrap other concurrency libraries and frameworks. with the proposed utilities, however, you could construct your own java.util.concurrent.threadpoolexecutor backed with managed threads:

 // can also use jndi lookup in method instead of injection
 @resource
 managedthreadfactory mtf;

 public executorservice getmanagedthreadpool() {
   // all threads created will be managed
   return new threadpoolexecutor(5, 10, 5, timeunit.seconds,
       new arrayblockingqueue<runnable>(10), tf);
 }

similarly, forkjoinpool can be parameterized with a custom forkjoinpool.forkjoinworkerthreadfactory implementation that delegates thread creation to the managedthreadfactory. while trying to implement such an adapter i unfortunately ran into the issue that fork/join uses a custom thread subclass ( forkjoinworkerthread ). this makes the task a bit harder, it’s constructor being package protected. and obviously i can’t test the code, since i’m not aware of any (public) jsr-236 implementation. furthermore, i believe such adapters for java.util.concurrent should be part of the spec. no need to force application developers to reinvent the wheel again and again!

now what?

when reading the jsr-236 spec it is clear that it was crafted in the ancient j2ee times. just look at the code examples in the draft spec (ejbhome interfaces, really?). cdi is never mentioned, and neither is fork/join or other relevant newer technologies. still, it’s clear that this spec will lay the groundwork for integrating modern java concurrency frameworks with java ee. but exactly how this will work out is too early to tell.

another obvious candidate for using the javax.enterprise.concurrent functionality is the batch processing jsr. there’s lot’s of work to do it seems. let’s hope that expert groups find enough time to join forces and move the java ee platform forward.

Java EE Java (programming language)

Published at DZone with permission of Sander Mak, DZone MVB. See the original article here.

Opinions expressed by DZone contributors are their own.

Popular on DZone

  • Hidden Classes in Java 15
  • SAST: How Code Analysis Tools Look for Security Flaws
  • Mr. Over, the Engineer [Comic]
  • Why Open Source Is Much More Than Just a Free Tier

Comments

Partner Resources

X

ABOUT US

  • About DZone
  • Send feedback
  • Careers
  • Sitemap

ADVERTISE

  • Advertise with DZone

CONTRIBUTE ON DZONE

  • Article Submission Guidelines
  • Become a Contributor
  • Visit the Writers' Zone

LEGAL

  • Terms of Service
  • Privacy Policy

CONTACT US

  • 600 Park Offices Drive
  • Suite 300
  • Durham, NC 27709
  • support@dzone.com
  • +1 (919) 678-0300

Let's be friends: