Skip navigation

In EJB 3.1 asynchronous client invocation semantics were introduced [1]. As the term already implies it addresses a clients need, however the specification has the construct such that is has become a bean developer concern. I think this is wrong.

 

Let me give a simple example. Suppose we would have developed some EJB. Now I want to build an application which wants to do an asynchronous request. In EJB 3.1 I would have to change the EJB to accomodate such a feature. Rather I would just want to call asynchronous.

 

So I started to fiddle some time ago to see if I can get a simple API with which asynchronous becomes a client concern. Leaving the aquiring of an EJB out of scope I can up with the following code [2]:

import static java.util.concurrent.TimeUnit.SECONDS;
import static org.jboss.beach.async.Async.async;
import static org.jboss.beach.async.Async.divine;

public class SimpleUnitTest
{
   @Test
   public void test1() throws Exception
   {
      SomeView bean = new SomeBean();
      Future<Integer> future = divine(async(bean).getNumber());
      int result = future.get(5, SECONDS);
      assertEquals(1, result);
   }

   @Test
   public void test2() throws Exception
   {
      CyclicBarrier barrier = new CyclicBarrier(3);

      SomeView bean = new SomeBean();

      async(bean).join(barrier);
      async(bean).join(barrier);

      barrier.await(5, SECONDS);
   }
}

 

So effectively I've got it boiled down to 3 methods:

public class Async
{
    public static <T> T async(T bean);
    
    public static Future<?> divine();


    public static <R> Future<R> divine(R dummyResult);
}

 

With the async method a regular proxy is transformed into an asynchronous proxy. Every method on it will be available for asynchronous client invocation.

The divine methods return the Future from the latest asynchronous invocation.

 

An assumption that also need to be mentioned, but is out of scope:

The caller environment has administrative operations to setup and control the asynchronous invocations. This is important so that asynchronous invocations within an application server can't overload it.

 

I'll put this proposal to the EJB 3.2 EG today to see gauge this. I'm equally interested in your reactions as well, so comment (or flame ;-) ) away.

 

[1] EJB 3.1 FR 4.5 Asynchronous Methods

[2] https://github.com/wolfc/jboss-beach-async

Filter Blog

By date:
By tag: