Async Beans Introduction

Async Beans is a feature in WebSphere 5.0 Enterprise. It allows J2EE applications to take advantage of threading (short lived aka pooled threads and long lived aka daemon threads). I'm just going to discuss how to use the threading in applications today.

It all centers around the com.ibm.websphere.asynchbeans.WorkManager interface. A web app or EJB can declare a resource-ref to one or more of these. These are bound to a physical WorkManager at deploy time. The administrator can create one or more WorkManagers. Each one is basically a thread pool. An application can be deployed to use multiple thread pools or a single one, it's just like a resource-ref to a DataSource.

The application component looks it up in its JNDI using the name corresponding to the resource-ref. This can be done many times but the same WorkManager is returned each time. If two application are bound to the same physical WorkManager then they share the WorkManager.

The main methods on WorkManager are startWork and join. The main interfaces to know about are Work, WorkItem and WorkManager. Work is simply a Runnable with an additional release method. So, make an instance of an inner class or a JavaBeans that implements the Work interface and then pass it to a WorkManager.startWork. You will be returned a WorkItem. These can be put in an array list and then provided to the WorkManager.join method. The join method allows the caller to block waiting for 1 or all Work's to complete. A timeout can also be specified.

The javadocs are here

When the Works are dispatched on a thread then the JNDI context from the component that called startWork is used. The Work cannot make global transactions but it can safely invoke an EJB that it looks up through an ejb-local-ref or ejb-ref and then use it to do any transactional stuff. If security is on then the credential from the caller of startWork is also present on the dispatching thread so the Work is running as the same identity as the caller of startWork.

Some variations of the startWork method take a WorkListener instance which allows events to be fired back as the Work is executed or when it finishes. Some also take a boolean 'isDaemon' which if true means that it's a daemon thread. In this case, I don't allocate it from a pool, instead I just spin up a thread for it.

The release method is there so that when the application is stopped, I iterate over the daemon threads and call this to give them a hint that they should stop.

There really isn't much to using it. I have another blog entry on this site showing how to use JMX to tune the thread pools associated with a WorkManager while it's running.

Once you get the hang of it then you can build pretty advanced J2EE applications. The commonest things I see are dynamic messaging, advanced threading models for processing messages and people using them to do tasks in parallel like database queries and calculations.

Startup beans are basically SLSBs which use a specific remote and remote home interface. If WebSphere sees one of these in an ejb module then when the module is started, we invoke the start method. The start method can be used to spawn threads or warm CMP caches etc. If the application stops normally then the stop method is called. There can be more than one startup bean in an application and they can be ordered with respect to each other.

I'll try to get permission to publish a messaging application which demonstrates how to do some useful things using async beans and JMS or Tibco.

Comments

[Robert Fletcher]

You need to provide a PINTER FRIENDLY link

thanx

[Simon Brown]

Nice overview, Billy - thanks for taking the time to explain these new EE features. :-)

[javajim]

in your previous blog entry "When MDBs aren't enough" you state that we cannot create threads at the servlet level because the j2ee spec says we cannot rely on that being supported. however, in this blog entry, you mention a websphere specific method for threading (even though it is not a j2ee standard, and thus support by other j2ee containers cannot be relied up.) so, we should not create threads in servlets, but it is okay to let vendor lockin api's create them?

[Billy]

Thats right, until the spec catches up, this is the only acceptable way to make threads, using vendor specific APIs that do what ever is necessary to make them supportable and managed.

[Jack]

I have built an application with a startup session bean. But when I started the application, thestart method was not called. Is there any other requirement to use it? Thanks a lot.

[Erich]

Can you please tell me what .jar file these asynchBeans reside in?

[Jim Cakalic]

It looks like Async Beans -- or at least WorkManager -- is going to be in WAS6. And it's encouraging that IBM is collaborating with BEA on this so it might make it into the J2EE spec. But since WAS6 probably won't hit GA for quite some time, do you think that WorkManager will be made available to us poor WAS-ND users?

Thanks
Jim

[Billy]

No sorry,
6.0 will have the commonj stuff inside it. I don't know of any plans for moving it back to 5.x although I can't say anything about stuff which is not officially announced by IBM means anything.

[Billy]

The jar is asynchbeans.jar in appserver/lib

[Someone]

I do not find the asynchbeans.jar. Where can I get it from?

[VP]

I am in the process of architecting an enterprise application which, in a nutshell, recieves large volumes of messages intermittently during the day from a series of sources via MQ. These messages are transformed, written to a database. The latter triggers the resultant transformations to be distributed to remote sites for purposes of querying at the remote site.

This solution in its current form (this is currently deployed and functional) is handling relatively small volumes as compared with the future requirements and is built using a set of C daemons reading from a message queue using the MQ Series API. The daemons are the message consumers and are the equivalent of the MDB with the exception that the current implementation manages its own transactions. I am having a religious debate here in that I am being challenged by the team with regards to the amount of additional complexity that would be introduced by bringing in a solution that leverages MDBs under WAS 5.1. My arguement is the following:

1. Scalability with MDBs is achieved easily by the addition of nodes / clones, controlling the pool sizes of the MDBs, configuration settings such as max listener sessions etc.. This would be in addition to MQ clusters. Can 2 MDBs belonging to 2 diferent nodes be consuming messages from the same logical queue manager within a cluser? My gut says "yes".

In the case of the current solution, this would have to be controlled by spawning of additional daemons bound to additional message queueus.

What is the overhead as far as performance goes introduced by the EJB container within WebSphere?

2. Manageability of the overall solution is much higher. Standard WAS plug-ins make the manageability of the MDBs a lot simpler as compared to the home-grown daemon version.

3. Delegation of distribution responsibilities, transaction management responsibilities, asynchronous message consumption responsibility to the container simplifies the programming model.

My questions are as follows:

Given that we have performance, reliability and availability as key NFRs that need to be satisfied by the solution, should I rethink the architecture vis-a-vis the use of WAS? I have some dated (2003) benchmarks run on the Windows 2000 environment from IBM that prove that a non-MDB solution is less efficient. I'm not sure that I would go by this, given that my current platform is Linux and WebSphere. Your inputs on this matter would be "muchas" appreciated.

Best regards
vp

[srimukha reddy]

could you please tell me,what is the alternatives for wait and notify() in ibms asynch bean...

[John McRobb]

I am using RAD6 and we don't have the asyncbeans under the 5.1 lib but do under the 6. I have tried looking on the advanced edition 5.1 install and it doesn't appear to be there either. Is there a patch that we can install and is it supported in 5.1?

Thanks

John

[Kwan]

I have a work manager asyncbean. This aysncbean call a sequence of work in Oracle. When one of the work in Oracle takes more than 30 minutes. The asyncbean hangs and no futher method got executed. Do you know if there any timeout for aysncbean?

[jagan]

Hi,

Could you please let me know where I can download asynchbeans.jar to work with WebSphere 5.1 / WebSphere Studio Application Developer 5.1.2

Thanks much for your help.
JAGAN

[Todd]

It looks like work manager asyncbean are only supported by websphere 5.x enterprise edition. Do you know if it is possible to get this feature working in Base WebSphere 5.1?

[Jaidermes Nebrijo Duarte]

I would like to see an Startup Bean complete example. I'm new in EBJ.

[zebra]

I dont understand , how I can configure a new work manager using websphere 5.0 adminstration console.
There is no mention for asynch beans or work manager in there.

[Ram S]

I having hard time understanding the async beans functionality. I am using Websphere 6.1 and I see that the documentation is quite inadequate except for a few basic examples.

This is my question;

I have a Stateless Session Bean. Could I start a Asynchronous Beans (IBM Websphere's solutions for asynchronous processing) using Workload manager from a stateless session bean?

I did some POC and I see that when I keep the transaction attribute as REQUIRED (container managed model) the stateless session bean creates a transaction upon entry into its method (I printed the localID and globalID from ExtendedJTATransaction using SynchronizationCallback). But, when I started the Asynchronous Bean from my SLSB and I print the transaction in the work object's run method the localId and globalID are 0 and null respectively.

My understanding was workmanager on start will create a new transactional context (local I guess) and run this. The above sounds like no transaction was created.

I would like to suggest this to my company as a possible solution, but, the inadequate documentation and the above behavior makes it difficult for me to decide.

Could you please tell me whether it is safe to use Async Beans?

Can I start Async Beans using WorkloadManager from a Session Bean (stateless)?

Or should I invoke get the workload manager from the pool and start EJBs (stateless) from the workload manager?

Any urgent help would be greatly appreciated.
Please advice.

Thanks.

I can't find the javaDoc of Async Beans. The link cannot be displayed