The Work Manager API is designed to allow the use of threading in a J2EE container. This article on DevX, called "The Work Manager API: Parallel Processing Within a J2EE Container," illustrates the Work Manager API, the lifecycle of events, and shows how the Work Manager API would be used in a container.

The example is based on WebLogic 9.0, which was released in July. There's also a JSR assigned for the Work Manager API, JSR-237, itself sponsored by BEA and IBM, but it has been in "expert group formation" stage since December 2003, much like JSR-235 (Service Data Objects) has. Originally targeted for J2EE 1.4, both SDO and the Work Manager have seen implementations moving ahead despite a lack of JCP involvement. Originally targeted at J2EE 1.4, the JSR for JEE5 (JSR-244) doesn't make any mention of this JSR at all.

Additional documentation on the Work Manager API

• Service Data Objects, WorkManager, and Timers from IBM's developerWorks site

It's a pretty nice API. We provide a fully clustered Work Manager implementation in our next (Coherence 3.1) release.

Peace,

Cameron Purdy
Tangosol Coherence: Clustered Shared Memory for Java

We provide a fully clustered Work Manager implementation in our next (Coherence 3.1) release.

Interesting. I've never used Coherence (and my copy of Distributed Hashmaps In Action is on back-order), so I have some naive questions:

1) The API does look very nice in its own right, but it looks like the primary motivation is to ensure that scheduled threads are managed by the J2EE container, thus ensuring that container-managed services are propagated to the threads. If Coherence implements the API outside of the parent container (I assume that Coherence can run inside of Websphere/Weblogic), doesn't that defeat the purpose?

2) What kinds of use-cases make it valuable to schedule arbtitrary user-defined work items in the context of a caching product? It seems like a lot of the obvious cases (timed expiry of cache values, etc.) would not require such a generalized API.

1) The API does look very nice in its own right, but it looks like the primary motivation is to ensure that scheduled threads are managed by the J2EE container, thus ensuring that container-managed services are propagated to the threads. If Coherence implements the API outside of the parent container (I assume that Coherence can run inside of Websphere/Weblogic), doesn't that defeat the purpose?

Our reasoning is very simple: We have customers that asked for the ability to do parallel processing of "work", either locally or in a cluster. We picked the JSR 237 API (e.g. over the J2CA 1.5 API) for this because it is application-facing and a good fit (e.g. wait for any, wait for all, etc.)

If you're running inside WebSphere, you can always use the WebSphere implementation, for example. This isn't an "add on" product for us, it's just another feature that we've been asked to support. It's not intended to displace container functionality that is already there.

(BTW - the J2CA 1.5 APIs that I mentioned provide the means for a product like ours to obtain "container happy" threads. In other words, we get to use J2CA, and our customers would use JSR 237.)

2) What kinds of use-cases make it valuable to schedule arbtitrary user-defined work items in the context of a caching product? It seems like a lot of the obvious cases (timed expiry of cache values, etc.) would not require such a generalized API.

I was referring to the "work" package, not the "timers" package. We've supported distributed and parallel work concepts for a couple years now, but this is a great API to wrap it up with.

Coherence has always provided much more than caching functionality. For example, financial services companies do massively parallel risk analysis (which is both data intensive and compute intensive) using a combination of our partitioned caching and our clustered agent invocation capability. The partitioned cache automatically load balances the data, and the invocation service makes sure that the agents are running in parallel on the servers, processing the data where it is partitioned to. The result is unlimited data throughput (all data access is local so you're talking about tens or hundreds of thousands of accesses per second per server), and data modifications are constant-order implementations (single-hop point-to-point updates to another server for redundancy purposes). The architecture provides unlimited compute throughput, since each server is running at 100% CPU utilization (no network or database latencies since the data is local), and the benefit of the dynamic data load balancing is that when you add more servers, each one automatically ends up with less and less work to do.

The really nice thing about the JSR 237 API is that it is general enough to support a push model, a pull model, local execution, distributed parallel execution, etc. Implementing functionality like once-and-only-once processing within a cluster (e.g. jobs that will get automatonically run exactly once regardless of servers starting, leaving, dying, whatever) is ordinarily a difficult challenge, but Coherence (which underneath the covers is just a transactional data grid built on an n-point completely peer-to-peer mesh) has all the necessary building blocks already there.

Peace,

Cameron Purdy
Tangosol Coherence: Clustered Shared Memory for Java

It sounds like Coherence is moving more into direct competition with the high-end (mostly non-standardized) clustering capabilities offered by Websphere and Weblogic.

There are clearly some differences (it appears that the app servers have a broader range of off-the-shelf clustered services, while Coherence has a leg up in addressing requests based on data location), but the overlap seems to be increasing.

Is there a line that you don't intend to cross, or are you heading to a point where you offer (Coherence + low-cost non-clustered app server) as a direct competitor to the high-end products?

It sounds like Coherence is moving more into direct competition with the high-end (mostly non-standardized) clustering capabilities offered by Websphere and Weblogic.

Coherence has supported transactional data and compute grid functionality for years now. We are very careful to avoid competing with our partners, such as IBM and BEA. (I am fairly certain that we do not directly compete, given how many of our customers use us in their apps that run on the high-end clustered editions of WebSphere and WebLogic.) We're not an app server or a container, and we work really, really well inside WebSphere and WebLogic (not to mention jboss and Geronimo and OrionServer and Resin and Oracle app server etc.) Our job is simply to make our customers' lives easier, and most of our customers use app servers like WebSphere and WebLogic.

There are clearly some differences..

In my experience, there are very few similarities. We do coherent clustered caching and transactional data+compute grids.

On the other hand, app servers over time are adding some of the features that we have, so I'd expect more similarities to emerge.

Is there a line that you don't intend to cross, or are you heading to a point where you offer (Coherence + low-cost non-clustered app server) as a direct competitor to the high-end products?

Our goal is to solve customer problems, nothing else. Our customers already have the app server problem solved, so honestly we don't get asked to provide an app server. Our customers already have good app servers (mostly WebSphere, WebLogic Sun and Oracle for big customers, and lots of Tomcat, jBoss, Resin and other open source across the board -- they're all very good at what they do).

So while we're very popular on the low end (e.g. a 100+ server J2EE clusters with a total hardware+software cost of less than $500k), we're also very popular on the high end (e.g. 24/7/365 equities trading systems, risk management, real-time compliance, credit card processing, package tracking and supply-chain/RFID, telco apps, airline/travel/hotel booking/reservation/pricing systems.)

We really wanted to build a company that wouldn't "get stuck in the high end". I have long believed that successful enterprise software companies tend to price themselves out of relevance -- and eventually out of existence -- so we've worked really hard to keep our software attractive to small- and medium-sized companies. While we have big customers with big applications (some that serve over 100 million pages a day or process tens of millions of transactions per day), we're also used by lots of small companies (there's a partial customer list at http://tangosol.com/customers.jsp).

Java has created an amazing marketplace. You've got some good high-quality solutions for free, and in the same market you have extremely expensive (and often very niche-specific) software solutions. You've got successful commercial and open source companies. There are solutions from the smallest (PDAs, Phones) to the largest (parallel sysplex mainframes, 1000+ server grids). We enjoy our role, being a little piece of this mosaic.

Peace,

Cameron Purdy
Tangosol Coherence: Clustered Shared Memory for Java

Cameron, how do you support the "JSR-237" API? The JSR *has* no published APIs - there's only the non-JCP API work done by IBM and BEA. Are you equating that with JSR-237?

I recently developed an implementation of the WorkManager API . This is used for internal testing as its a nice API for layering load test cases on.

Implementing the API based on the documentation provided was an eye opener to the various implementation approaches especially considering the last time I checked most of the WorkManager API examples in the specification could fail with a particular sequence of method invocations and event dispatches. I believe the example code did factor in that a WorkEvent might be dispatched before the actual schedule method had retured with a WorkItem.

JXInsight 3.3 which is schedule for release later this month will support DISTRIBUTED tracing and profiling of WorkManager Work/WorkItems with the ability to relate the scheduling thread execution thread context (callstack, trace stack, transactions, additional profile info) with that of the execution (run) thread.


Regards,


William Louth
JXInsight Product Architect
JInspired


"Java Enterprise Edition (JEE) tuning, testing and tracing with JXInsight"
http://www.jinspired.com

Cameron, how do you support the "JSR-237" API? The JSR *has* no published APIs - there's only the non-JCP API work done by IBM and BEA. Are you equating that with JSR-237?

I assume we're implementing those same APIs.

Peace,

Cameron Purdy
Tangosol Coherence: Clustered Shared Memory for Java

It's also in WebSphere 6.0 (shipped in Dec, 6.0.2 just went out the door) which also includes the full async beans APIs I did before this. The main difference besides interface surface improvements is that the async beans APIs include the EventSource APIs which are really handy when doing callbacks or using these APIs with public libraries like concurrentj etc. Just make a ThreadFactory using async beans and then use the concurrentj APIs instead of commonj/async beans if you want.

Billy (IBM)
http://www.billynewport.com

It's also in WebSphere 6.0 (shipped in Dec, 6.0.2 just went out the door) which also includes the full async beans APIs I did before this. The main difference besides interface surface improvements is that the async beans APIs include the EventSource APIs which are really handy when doing callbacks or using these APIs with public libraries like concurrentj etc. Just make a ThreadFactory using async beans and then use the concurrentj APIs instead of commonj/async beans if you want.Billy (IBM)http://www.billynewport.com

I would like to know if the WorkManager implementation supports propagation of transaction context from the calling thread into the threads doing the work and if not, is it expected in future implementations of WorkManager ?

The reason I am asking this is because in my application (we use Websphere 5.1 Network deployment edition), we use stateless EJB's to co-ordinate an XA transaction which involves a put to an MQ queue and write to a DB2 database.

Currently, we have to make these steps sequential (as part of the EJB thread) - so I was wondering if MQ put and DB2 update could have been done in parallel had we used the work manager concept (basically the EJB method parcels out the MQ write/DB2 update to 2 different workmanager threads and waits for them to finish).

However since both MQ put and DB2 update must be part of same global transaction (so transaction is rolled back if either one fails) - this means transaction context associated with the EJB method must be propagated to each such Work manager thread.

regards,
Sanjeev.

I had exactly the same question in mind.

In the WebLogic documentation for WorkManager, here's what is said about this:


When a Work is scheduled, the declared context that is present on the thread (the J2EE context) will be saved and propagated to the asynchronous methods that are executed. This J2EE context at minimum will contain the java:comp namespace and ClassLoader of the scheduler unless specified otherwise. Other J2EE contexts such as security or a transactional context may be optionally added by the application server vendor.


This is a bit vague. Are the asynchronous methods invoked in the same transaction as the calling thread? under the same security principal? What about exceptions that could be thrown in the run method: do they cause the transaction to be marked for rollback? Do they cause the other threads running in parallel to be released? What about timeouts configured for the transaction of the calling thread?

The article lacks details about all these questions.

I was playing around with this a while back and I think, in WebSphere, if you pass the JTA userTxn to child threads and use it in the child threads, the work performed in the child threads is performed in the same context as the parent thread. So you are not forced to do your work sequentially. I was trying this out a while back and my recollection may not be correct, so I could be wrong but a quick test should prove it.

I was playing around with this a while back and I think, in WebSphere, if you pass the JTA userTxn to child threads and use it in the child threads, the work performed in the child threads is performed in the same context as the parent thread. So you are not forced to do your work sequentially.

That should not be possible, since the UserTransaction is a stateless object according to the API documentation (the state is bound to the thread, not to the UserTransaction object).

Further, the specs on which JTA/JTS are built have explicit thread-local semantics, requiring the actual transaction to be suspended on one thread before it can be used ("resumed") on another.

The resulting behavior _should_ be that using UserTransaction on the different thread _should_ create a new transaction if you call begin() and should commit it completely independently of the other thread if you call commit(). (Billy?)

Peace,

Cameron Purdy
Tangosol Coherence: Clustered Shared Memory for Java

Each thread has its own transaction. UserTransaction is actually not a stateless object (depending on the implementation). Various implementations even between product versions can vary. The only safe way is to look it up and cache per thread which is all I'd recommend people do.

Sharing transaction between threads isn't possible and even if it was would be a nightmare to support. It would also mean things we'd assume are single threaded and don't need synchronization would now need synchronization and slow down.

Camerons interpretation is absolutely right. Different thread, different transaction. Starting a work, pooled or daemon has no impact on the transaction on the current thread.

I had thought about a suspend/resume semantic for J2EE transactions. This would cause the current transaction to be suspended and resumed on the new thread. I liked it. The thread that called WorkManager.startWork would then have no transaction present once the call returns.

But, I had to punt on it as it would ripple through a lot of the application server (CMP caches for example, connection handles in J2C), the ripple was too big to contain. Personally, I would love a suspend/resume semantic in J2EE in any context. This would allow asynchronous servlets and EJB calls and would allow very scalable applications to be written instead of whats possible today using the 100% synchronous approach adopted in the specs.

The best part of the commonj stuff was just working with John, Naresh and Zach from BEA on cleaning up the APIs for the subset thats there. Being in the API business is tough. I'm usually never happy with the API I ship and always want to 'fit' it but never can because of support issues and N-2 API compatibility etc.

Billy

I wrote a fairly large document on using async beans in 5.x. You can find it here http://www.devwebsphere.com/devwebsphere/2005/06/async_beans_pro.html

Billy

I am using this guide as I learn the Async Beans API. It's been extremely helpful. Thanks! I did notice something that I would like to comment on (at the risk of getting back a 'duh!' ). This also relates to the above/below transaction discussion. I have written a test has a very distinct result and I believe it's related to how WorkManager deals w/ transactions. I have a Stateless Session Bean which has a resource-ref to an Oracle 10g (using XA driver) database. The Stateless Session Bean has a transaction type of "TXN_REQUIRED" for my test method. The test method grabs a connection to the db and does an update (closing stmt/connection immediately). Then, it invokes a single Work thread via startWork(Work). The Work impl uses the same database resource (not same reference, it gets a new instance) as the calling EJB and does an update (closing stmt/connection immediately). The WorkManager then does a join(..) and waits for the Work to complete. In this test case, the db update in the Work thread will block until the timeout on the WorkManager.join(..) expires. After that, the calling thread resumes and the Work thread resumes. Both the calling thread db update and the work db update are successful. I know it's related to the join because the 'hang time' directly correlates to the join timeout time. I know we should be able to make db inserts from a Work. Can we share the same db resource between calling client and Work instances if the client is in the middle of an active transaction at the time of the call to WorkManager.startWork(..)? From reading the doc, the expected result for me was that nothing would block, but if one of the Work threads failed, their database updates would not rollback. However, if the calling thread did not handle the exception, it's db update would be rolled back. I plan to try EJB Work impls anyway because I want the Work threads to rollback, however I was curious what causes this scenario. Thanks, Sean

An update.. It was due to the fact that I was updating the same db record in both threads. Makes sense now.

Each thread has its own transaction. UserTransaction is actually not a stateless object (depending on the implementation). Various implementations even between product versions can vary. The only safe way is to look it up and cache per thread which is all I'd recommend people do.

Billy, could you please elaborate a bit on what state a UserTransaction could potentially hold? In all scenarios I've encountered, UserTransaction actually was a stateless, shared object (or at least seemed to be).

It's not uncommon to look up the UserTransaction once and cache it for an entire application. Which J2EE products and versions do/did not support such a shared UserTransaction object but rather require a per-thread lookup?

Juergen

Would like to mention that sharing of transaction between the thread calling WorkManager.schedule() and the executing thread isn't supported in WebLogic as well.

For those who are interested to use Work Manager API on older J2EE containers such as WebLogic 8.1 there is an opensource backport implementation based on a standard J2EE services. Project is hosted on BEA's dev2dev CodeShare site. http://xcommonj-work.projects.dev2dev.bea.com/

Here is the voting comments from Oracle & Sun

On 2003-12-15 Oracle voted Yes with the following comment:
==========================================================

While voting to support the technical work in this JSR, Oracle is concerned about the manner in which it was introduced into the JCP. IBM and BEA, by publishing specifications and publicly committing to implement them as published in the very near term, are dramatically altering the JCPs normal mode of operation; instead of working with major stakeholders to develop a consensus specification, they are imposing on the community their preferred approach and trying with their combined market shares to assure its adoption.

Oracle also has concern about the proposed licensing approach. We appreciate IBM and BEAs willingness to revise and clarify the licenses, especially to remove any wording that could be construed as viral and to specify the commercial terms that will apply when the RF option is not chosen. However, we have questions about several aspects of the new licensing approach that we believe require more thorough consideration. These include questions such as:

1. Should the RF commitment be more symmetrical? That is, if Oracle commits to provide RF terms on all future JSRs for which we serve as specification lead, should IBM and BEA make some similar commitment to offer RF terms on their future JSRs as well?

2. If the proposed licensing approach becomes wide spread, is there a potential for conflicting commitments?

3. Will the availability of the RF option result in the commercial terms getting insufficient review?

4. Will the availability of the RF option result in fewer organizations willing to take on the role of specification lead?

On 2003-12-15 Sun voted Yes with the following comment:
=======================================================

The licenses contained in the JSR submission had a number
of problems. Sun would like to thank the spec leads for
acknowledging the issues and agreeing to resolve them.

Sun would also like to thank the spec leads for their
constructive discussions on the relationship between this
new JSR and the existing JSR-166, and for their willingness
to attempt to base this JSR on the JSR-166 APIs.

AFAIK currently only IBM/WebSphere and BEA/WebLogic support this API/spec (since its "their" spec)... I wonder whether and to which degree other vendors (will) support this "CommonJ" spec... I'd very much like to have the capabilities available provided by it but other than BEA's J2EE 1.3 based implementation there doesn't seem to be a lot of support (especially from Sun JSAS, JBoss (they have their own async API), Geronimo and Oracle).
On the other hand, there doesn't seem to be a similar "replacement" API providing async-call capabilities (other than using JMS - quite clumsy).
Anyone have further info?

regards,

Messi

What I find amazing about this is that J2EE has still failed to address a key requirement of many real enterprise applications - the ability for applications to create their own threads within a J2EE container and have the various contexts available.

Then again, it did take a very long time just to get (a rather limited) way to receive JMS messages, not to mention the debacle of EJB persistence.

I'm glad that IBM and BEA have stepped forward with a proposal for filling this hole. Perhaps Sun and the other vendors should take a leaf from their book.


Adam

Adam, this is what the JCP is for - "find a hole, plug it by using experts to figure out a solution."

What worries me is that IBM and BEA have, for better or for worse, done that - and then abandoned the JCP process. That's not "community," that's just being a set of mavericks. That works in some cases, and it also serves to remove community input into the process - for example, did IBM and BEA get it right? I hope so, because they certainly don't have any public responsibility to the JCP in this.

I prefer customers rather than experts. A lot of 'experts' don't think this kind of function is needed at all.

Sorry, I disagree, thats what the market is for not the JCP. If I waited for the JCP or any other standards process, I'd have a lot of miffed customers because I'd have told em come back in 3 years. I can't and won't do that.

As for community input, I completely disagree, we've had customers using async beans since V5.x on real projects. There is more than one way to get input and frankly input from people using the APIs for real projects is the most valuable input of all.

I don't want to sound inflammatory but frankly the wording of your post upsets me.

Billy

I prefer customers rather than experts. A lot of 'experts' don't think this kind of function is needed at all. Sorry, I disagree, thats what the market is for not the JCP. If I waited for the JCP or any other standards process, I'd have a lot of miffed customers because I'd have told em come back in 3 years. I can't and won't do that.As for community input, I completely disagree, we've had customers using async beans since V5.x on real projects. There is more than one way to get input and frankly input from people using the APIs for real projects is the most valuable input of all.I don't want to sound inflammatory but frankly the wording of your post upsets me.Billy

+1
Could not agree more!
Finally a posting coming from the real world.

No need to be upset. (I'm certainly not upset, personally.)

Sure, customers are great - but what prevented moving forward with the JCP? "Come back in three years" is accurate when demand is light, but surely a work manager API like this could have progressed quickly, and should have. Customer feedback is part of the JCP process, after all, so you'd not "miss out" on anything, and the API would be generally available and standardized across containers under the auspices of the JEE standard.

If "a lot of experts" don't think it's needed, well... that's great, they don't have to participate. The JCP approved the original JSR; it's been in "expert group formation" ever since, and surely there are "some experts" who want it, judging by the fact that you do have customers who want and need this kind of functionality.

What I find amazing about this is that J2EE has still failed to address a key requirement of many real enterprise applications - the ability for applications to create their own threads within a J2EE container and have the various contexts available.

This *is* possible, both with JSR-237 and with the current connector (J2CA) API.

However, the J2CA approach is primarily for JDBC driver authors, mainframe-connector authors, third party JMS authors, etc. In other words, it is kind of "odd" from an app point of view to use J2CA to create your own threads, because you actually have to create an adapter and a .rar to accomplish it. (Think about how complex that is -- you can either call "new Thread()" or build a J2CA adapter and package it up with some XML files into a .RAR file that you deploy into the app server.)

That's why I like JSR 237 -- it provides a true "app facing" API that allows you to spin off work.

OTOH, the J2CA approach is much better if you want to kick off a daemon that will run for the duration of the server, for example.

I'm glad that IBM and BEA have stepped forward with a proposal for filling this hole.

Ditto, and (my own $.02) I think that the API is well done.

Peace,

Cameron Purdy
Tangosol Coherence: Clustered Shared Memory for Java

Cameron, I think the API is workable, too - that's why its non-inclusion in the JCP concerns me. It should be in the JCP. It should be in the next revision of Java, Enterprise Edition. Yet it's not, and it can't be, under the current circumstances. I have a hard time saying "JSR-237" because, while that may have been the original intent, what's been implemented is simply parallel with JSR-237, it's not the same as JSR-237.

API is so workable in my opinion

buffalo search engine optimization

Hi, I am scheduling work using WorkManagerAPI. My Scheduled work is accessing the shared resource which is hold by some other thread. My question is, How can I block/wait scheduled work until other Thread releases the resource. Is there any way to block until accepted and block until completed. thanks, Madhu

hey Madhu

Great to know about that.any changes?

stork club new york