The wise work manager for context-based scoping

Discussions

News: The wise work manager for context-based scoping

  1. A JavaWorld article, "The wise work manager for context-based scoping," addresses the Work Manager API, a specification backed by IBM and BEA, for use in Java EE to support management of threads in a Java EE application server. This has applications in long-running processes, where applications need to "spin off" tasks and manage them. The article uses an enterprise application as an example, where one startup servlet takes six minutes (for example). The article suggests that using the Work Manager can spin off startup into an server-managed thread, reducing startup because the servlets can now fire off tasks and continue, instead of effectively blocking. The article also uses as a premise that threads shouldn't be started by deployed code in an application server.
    It's a long-standing rule of thumb that we should not use java.lang.Thread within a Java EE server's servlet or Enterprise JavaBeans (EJB) container. The reason is that a managed environment should have complete visibility over all spawned threads; when users create their own threads, visibility goes by the wayside.
    Note that it is, indeed, a rule of thumb and not a mandate; there are application libraries that start up threads in Java EE without (too much) problem. However, the point about visibility is very accurate; threads started by user code in Java EE require careful management. The Work Manager API has a JSR associated with it, but that JSR has apparently been abandoned in favor of an independent specification on the parts of BEA and IBM. As such, it may take a while to reach broad appeal.

    Threaded Messages (21)

  2. Here is another example of using a distributed version of the WorkManager API in a standalone Java application cluster - Tangosol's Coherence WorkManager. http://www.jinspired.com/products/jxinsight/coherencework.html I have recently wrote a complete implementation of the WorkManager API for a large software company that also occasionally sells printers & cartridges when they used our product and services in improving the performance and scalability of a solution to migrating customer databases between different versions of a product. Nice and simple API but with a or two little gotcha's (non-specified post-conditions) you have to take into account when using & implementing it. In fact I think the code examples shipping with the specification had this bug which I must look up again. By the way this reminds me to create a much larger cluster setup of the Coherence WorkManager implementation and create some "artistic" visualizations of the work items executing across the grid. I am sure it would be beautiful and insightful to see how the flow and resource consumption patterns. kind regards, William Louth JXInsight Product Architect JInspired "Java EE tuning, testing, tracing and monitoring with JXInsight" http://www.jinspired.com
  3. I think it's good to see an article about this. One of the reasons I decided to add this capability to the J2EE environment was basically that this was sorely needed and holding back J2EE adoption for advanced applications which could not survive with the simplistic container managed threading scheme used by application servers. WorkManager allowed threads to be created by applications, be managed by containers and have the necessary managed context from the managed thread that created it. The authors point about release shouldn't be called by an application is false. Applications can start threads and may need to stop them if they are no longer required. Of course, an application can implement a Work such that a 'release2' method is present but you may as well call release if thats what you want to do. Billy
  4. In IBM WebSphere, it is called Asynchronous Bean (I think this name describes the behavior better than Work Manager). It has been available in WebSphere for about 3 years now. One of our applications that handle huge number of requests (and where saving of a few miliseconds in processing a request is considered an achievement), use Asynchronous Beans. It has been working very well so far. Shahid. Warren, New Jersey.
  5. On Bills comment. Commonj had to work on Java 1.4 so no concurrent stuff and the concurrent JSR wasn't final when we did it in any case. Doug did make some changes for us in his JSR to accomodate 236/237 and I was very grateful for that cooperation. The JSR 236 stuff is base on Dougs work and uses the same APIs where at all possible. Of course, no dates for when that JSR makes it out the door. Chris Johnson and I wrote a developer works article on using a WorkManager with as a ThreadFactory for a J2EE server with a Java 5 JVM if anyone is interested in using threads but want to use the java 5 thread classes as an API.
  6. On Bills comment. Commonj had to work on Java 1.4 so no concurrent stuff and the concurrent JSR wasn't final when we did it in any case. Doug did make some changes for us in his JSR to accomodate 236/237 and I was very grateful for that cooperation.

    The JSR 236 stuff is base on Dougs work and uses the same APIs where at all possible. Of course, no dates for when that JSR makes it out the door.

    Chris Johnson and I wrote a developer works article on using a WorkManager with as a ThreadFactory for a J2EE server with a Java 5 JVM if anyone is interested in using threads but want to use the java 5 thread classes as an API.
    Yeah, Doug tried to recruit us for this JSR I think...We turned him down because BEA/IBM were trying to muddy JCP rules a bit with this JSR's charter. I'm glad to hear that Doug is driving the API of this spec though. We couldn't really think of supporting it technically based on the older APIs.
  7. Put the Thread Pool in the JDK[ Go to top ]

    Why is the Work Manager API part of Java EE and not just part of Java SE? Most apps need to use multi-threading in some capacity. The trend in hardware has been toward multi-cpu and multi-core machines - increasing the need for multi-threading for scalability. .NET provides a basic threadpool. This allows core framework classes to leverage the pool for asynchronous invocations. Java could provide similar capabilities without requiring an app server. The java community has already been down this road with EJB's. Just put the thread pool API in Java SE with a straightforward implementation. App server vendors can provide more sophisticated implementations as required.
  8. The WorkManager API is not part of Java EE it just happens to be supported within two leading application server platforms - BEA and IBM. There are implementations for the Java SE platform. One could also implement the WorkManager API to simplify and standardize the coding of such constructs across one's own application(s). regards, William
  9. Thread Pool for Java SE[ Go to top ]

    How does the Work Manager API compare to the Task Scheduling Framework (java.util.concurrent.*) when used on the Java SE? Regards, Taras
  10. Needs to be in SE[ Go to top ]

    JSR 237: Work Manager for Application Servers The JSR specifically references Application Servers. In any case, the work manager is outside the scope of SE. Unless the thread pool is integrated into the core JDK, then it is unavailable for SE classes to leverage. How convenient would it be to do the following? OutputStream output = .. create output stream output.writeAsync(mybytes); This can be provided in .NET since a thread pool is available for all classes running in the managed environment. Mike http://www.jroller.com/page/mrettig
  11. Re: Needs to be in SE[ Go to top ]

    Hi Michael, If you looked at the link I provided in my first posting you will see the usage of the WorkManager API in the context of a simple cluster of Java SE applications. The API has no explicit ties to J2EE. None of the J2EE API's (Contexts) are referred to within the API. All the transference of the security and transaction context is hidden within the implementation. If you do not need this as is the case in the context of a JSE application then you can use any other implementation. It is worth noting out that this is an API with interfaces devoid of class implementations. You can have the a JSE application use the API today but first you need to get a useful implementation that is reliable and performs well. Is there not an open source implementation of this API already or is it unfashionable to not reinvent the wheel again. There was a back port of the API on BEA for older WebLogic releases that was made available with source I think. I am not sure how clean the implementation for usage outside of a container environment. regards, William
  12. Why is the Work Manager API part of Java EE and not just part of Java SE? Most apps need to use multi-threading in some capacity.
    First of all, I completely agree that most applications need some sort of custom multi-threading these days, spawning off asynchronous units of work. Standalone applications have always been doing this anyway... It's just a historical problem in a J2EE environment, and unfortunately remains to be a problem even on Java EE 5. While people have been successfully using Quartz and co in a J2EE server, there has been no 'proper' way of starting async jobs (from within an applicaiton) in such an environment, with the full J2EE thread context exposed to the asynchronous tasks as well as the server being in charge of task priority management. As a consequence, standard usage of Quartz - with its internal thread pool - is not officially supported on WebLogic or WebSphere. Enter the CommonJ Work Manager API and its sibling, the CommonJ TimerManager API: This is simply an API for asynchronous execution in a managed environment, done as a BEA-IBM joint project to make it available in J2EE 1.4 environments already (instead of, say, Java EE 6 or Java SE 7). Of course, this is "just" a thread executor abstraction, so it is somewhat similar to JDK 1.5's "java.util.concurrent" executor interfaces... Enter Spring 2.0 and its TaskExecutor abstraction: This is a simple executor interface with a variety of out-of-the-box implementations: e.g. for the "java.util.concurrent" ThreadPoolExecutor as well as a CommonJ WorkManager. Application components typically work at the TaskExecutor interface level, with a concrete instance obtained through Dependency Injection. The configuration then decides which TaskExecutor implementation should be used at runtime. Spring 2.0 already broadly supports the TaskExecutor abstraction for a variety of usage scenarios: from Spring's JMS message listener container to Spring's Quartz support, which all allow for configuring any TaskExecutor as backend (allowing Spring-managed message listeners and even Quartz to work with a CommonJ WorkManager, fully supported on WebLogic and WebSphere)! Of course, the TaskExecutor abstraction is available for custom usage as well... http://www.springframework.org/..../task/TaskExecutor.html http://www.springframework.org/..../jms/listener/DefaultMessageListenerContainer.html#setTaskExecutor http://www.springframework.org/..../scheduling/quartz/SchedulerFactoryBean.html#setTaskExecutor Juergen (Spring Team)
  13. Interesting... It is pretty close to the JCA 1.5 Work Management Contract... Ganesh
  14. Interesting... It is pretty close to the JCA 1.5 Work Management Contract...
    Yes, it is very similar in design, which is natural since they essentially serve the same purpose. The main difference is that the JCA WorkManager is only available to JCA 1.5 Connectors (via their BootstrapContext), whereas the CommonJ WorkManager is intended to be used within J2EE applications (as contained in WARs and EJB JARs). The resource adapter nature of the JCA WorkManager API also shows in advanced features, such as passing in an ExecutionContext that indicates an 'imported' XA transaction. This is only relevant for EIS connectors, not for applications. All an application really needs is a straightforward way to kick off an asynchronous task... Juergen
  15. All an application really needs is a straightforward way to kick off an asynchronous task...
    I actually thought one of the (additional) important benefits of the WorkManager API was the event mechanisms as well as the co-ordination of the multiple units of work via the waitForXXX methods. I rarely just run an asynchronous task ("fire and forget mode") which is what the Spring task executor class limits the problem space to though there is a Spring bean class that implements the commonj.work.WorkManager interface and delegates calls to an underlying instance. regards, William
  16. I actually thought one of the (additional) important benefits of the WorkManager API was the event mechanisms as well as the co-ordination of the multiple units of work via the waitForXXX methods. I rarely just run an asynchronous task ("fire and forget mode") which is what the Spring task executor class limits the problem space to though there is a Spring bean class that implements the commonj.work.WorkManager interface and delegates calls to an underlying instance.
    Indeed, the present Spring TaskExecutor abstraction reduces the API to the absolute minimum. We do plan to extend the abstraction beyond fire-and-forget, but that's not the case in Spring 2.0 yet. That said, the typical need for an async unit of work can nicely be handled with TaskExecutor and corresponding Runnable implementations, potentially with the Runnables giving specific callbacks themselves once they're finished. Essentially, TaskExecutor is not meant to be a comprehensive API in the first place: It's rather the simplest low-level abstraction "that might possibly work". Currently, it is perfectly sufficient for serving as backend for Spring's message listener containers, and also as execution backend for Quartz - with Quartz then providing flexible scheduling and listening facilities on top of it. Of course, a CommonJ WorkManager can also be used/injected directly within a Spring environment, either through a straight tag or through referring to Spring's WorkManagerTaskExecutor (which implements both the TaskExecutor interface and the WorkManager interface, delegating all calls to a native WorkManager underneath). Same for a java.util.concurrent ExecutorService, which can of course also be used/injected in native form, if desired. Juergen
  17. One thing that I did ask about a while ago to the Spring team was about how to use this API for getting a transaction context to be passed to multiple threads. The application in question is an analytic application. If I have say 32 nodes in a cluster each with a similarly structured database but with the tables partitionning data according to known metadata attributes then I can optimize queries for each of the 32 nodes and send off these queries in parallel. However I want them to run in the same transaction context. This doesn't look possible yet. Any ideas? Michael BearingPoint France
  18. Would you really want to use the same transaction context (XA) to query 32 databases? Can you describe the business level transactional semantics so that we can suggest an optimal resource transaction mapping. The overhead for the distributed transaction co-ordination across the cluster would be significant. Judging from the brief description below you are talking about XA and not just for the management of two or more collocated resources. What external transaction manager would you be using to manage all of this and does the underlying middleware platform support marshaling of the tx context over the wire to each cluster as well remote co-ordination across associated resources. Regards, William
  19. OLAP not OLTP[ Go to top ]

    I think the main point here is that I'm dealing with OLAP and not OLTP. The way most software in this space functions is that you query one database and that database works out how it queries 32 different nodes for you. That is the complexity is pushed behind the DB. But since I want to lower the cost of this stuff, open source is a good option, and there you still need the powerful parallel query database behind the scenes. At present the usage patterns for an OLAP database are mainly a large batch update at night and then a few thousand read-only queries during the day. One query can be translated into about 10 or 20 different SQL queries on just one collection of tables. If you partition the tables over different nodes you can run them in parallel and get a speed improvement. E.g. show me the top 10 products in the last month, sorted by volume of units sold, and then show me this distribution over the 3 contintental business units along columns. If I have to really summarise a few billion rows to get this the query never returns. Instead we pre-build aggregate tables in a batch job. That requires knowing a bit more about the sorts of queries that will be asked. But if I put German data on one node, French data on another, US on another etc, I can consolidate a lot of this query in parallel. The point of the transaction really is to maintain consistency in case there is a concurrent write taking place. This is because the data is exploding, the bathc window is getting smaller as some parts of the analytical problems are being pushed into the operational system. E.g. for an airline company: a plane is late. It will arrive in 20 minutes. Who are the best customers on the plane? According to their profile, who is most likely to go to the competition if we don't find a solution? How long to walk in the airport to connecting flights? How to negotiate seats on which flights ... get this all organised without human interaction. This is real-time BI and requires some heavy duty architectures. Since now, data is being written and read at the same time, I just want a common view of the data across data sources. This could be done just with a transaction ID in the where clause, but I wanted something a little more robust. I hope that clears it up.
  20. Joe Good choice for content. There is a worrying degree of ignorance out there about how safely to start up threads in a Java EE env. Last week I was a bit shocked when giving a presentation at a financial institution in NYC that I ended up having to spend a couple of minutes explaining why simply spawning threads in WebLogic was Not A Good Idea. The Work Manager API addresses an important need. Rgds Rod Interface21 - Spring from the Source: Support, Training, Consulting
  21. We use JMS for thread spawning: The starting thread (e.g. SLSB) sends n JMS messages which contain the spawn information to n MDBs (message facades) and this creates n spawned threads (e.g. in SLSBs). It works very well and you stay standard conform. Regards, Roger
  22. why a new API?[ Go to top ]

    I looked at this JSR over a year ago and one thing that popped up at me is why are we creating another API for spawning threads when one already exists in java.util.concurrent? Since java.util.concurrent already has a very nice, battled-tested SPI, why not define the Java EE integration points and reuse these interfaces? ON a side note, we've done some extensions to our EJB3 container to allow for asynchronous processing using the Future API provided by java.util.concurrent. Basically you can take any existing Session bean interface and invoke on it asynchronously with no code. Tx and Security context is automatically propagated to the new thread.
    MySessionBean bean = jndi.lookup("..."); MySessionBean asynch = Asynch.getAsynchronousProxy(bean); asynch.add(1, 1); // fires operation in background with same TX and security context Future future = Asynch.getFutureResult(asynch); int result = (Integer)future.get();