What are specs JSR-236 and 237, their state, explain the historical hacks around WorkManagers and that they are now designed to be used inside connectors only.
To be clear, there has only ever been one official, spec-defined WorkManager - the JCA WorkManager. The JCA WorkManager was always meant to be used exclusively within JCA Resource Adapters. A generic WorkManager that could be used outside the scope of JCA was introduced for spec consideration via JSR-237 in 2003. IBM and BEA had already implemented this idea but for whatever reason the JSR was withdrawn in 2005. Then the CommonJ WorkManager implementation popped up and started abusing the JCA WorkManager available within JBoss AS and then Spring followed suit with their JBossWorkManagerTaskExecutor. This, of course, has led to all kinds of confusion including threads like this where users like you complain that they can no longer exploit spec-compliant components in non-spec ways.
I understand we could use JMS but that would imply additional marshalling of potentially big objects.
If you're invoking a bunch of web-services then I can't imagine application performance is your top priority.
As for EJBs, I also understand it might be a solution technically but some places (including ours) made a choice of not using them (favoring a spring-only approach).
...Maybe it is time to reconsider this, though!
Choosing not to use asynchronous session beans is up to you. However, it makes little sense to complain that you can't do what you want when you've thrown out what is arguably the best solution available to you now.
I'm no webservice expert, but you might also consider asynchronous web service invocation which has been available since JAX-WS 2.0 (which was released in 2006) which was part of Java EE 5. This article might be helpful toward that end.
That would do the jobs for us while respecting the way workmanagers are now designed to be used in JB7.
I don't want to belabor this point, but I do want to be clear. The design and intended use of the JCA WorkManager hasn't changed in JBoss AS7. The JCA WorkManager in all versions of JBoss AS was never meant to be used in a generic way. JBoss AS7 simply removed the ability to acquire a reference to the JCA WorkManager via JMX which meant things like Spring's JBossWorkManagerTaskExecutor could no longer abuse it.
I like those "Aha!" moments: Your suggestion about asynchronous web services call is very interesting.
I've come across this thread and I just want to confirm my understanding. I have the following use case:
- a request comes in and gets split up in chunks. Each chunk has various dependencies on other chunks
- I want to execute each chunk and when they finish execute any depending chunks of work.
- At the end (or as we go), I collate everything and return to the user.
The call from the user needs should ideally be blocking, but step 2 should ideally be parallelised. Some of the work will be external calls to web services, others are in-app code executing, perhaps on the result of previous chunks, perhaps on stats/history of requests so far, etc.I also want to prioritise/schedule the work slightly differently. So for example, I want more threads available to do some web service calls than to do in-app stuff. And I may want to scale some areas of work and leave others as is.
So, I guess my questions are as follows:
- Is using a work manager an appropriate use case here?
- I'm confused in terms of what is meant above by "using JCA WorkManager in a general context rather than from within a JCA Resource Adapter". If I implement a Resource Adapter for a JBoss work manager that enables me to do the above, I'm presumably just exposing the work manager API and therefore probably come under the first of the two propositions
- What's a good use case for using the JBoss work managers? I found a lot about when not to use it, but what's a good time to use it? i.e. when would one implement a JCA Resource Adapter, for what purposes?
- I'm current using Tomcat with a view of moving to JBoss very shortly. My app uses Spring. Do I have any options that mean I don't have to re-implement much when I do the migration.
Is using a work manager an appropriate use case here?
You can only use the JCA WorkManager (i.e. the only WorkManager in JBoss AS) from within a JCA Resource Adapter. So if a JCA Resource Adapter is appropriate for your use-case then the answer would be, "yes."
I'm confused in terms of what is meant above by "using JCA WorkManager in a general context rather than from within a JCA Resource Adapter".
In previous versions of JBoss AS it was possible to get a reference directly to the JCA WorkManager. This allowed abuse because components that were not JCA Resource Adapters would use the JCA WorkManager to execute arbitrary work. In JBoss AS7 this is no longer possible. In order to get a reference to the JCA WorkManager you must implement a JCA Resource Adapter.
If I implement a Resource Adapter for a JBoss work manager that enables me to do the above, I'm presumably just exposing the work manager API and therefore probably come under the first of the two propositions
I don't see why you would be "just exposing the work manager API." Your JCA RA could have an API specifically suited for your business purpose.
What's a good use case for using the JBoss work managers? I found a lot about when not to use it, but what's a good time to use it? i.e. when would one implement a JCA Resource Adapter, for what purposes?
JCA is the "Java Connector Architecture" and it's geared toward integrating (i.e. connector) to other enterprise information systems (i.e. EISs) in your environment. There's lots of good information on the Internet about what JCA is good for. It's up to you to decide if it fits your use-case. However, it's worth noting that you can probably do everything you want with JMS and there's a good chance that asynchronous Session Beans could fit your need as well.
I'm current using Tomcat with a view of moving to JBoss very shortly. My app uses Spring. Do I have any options that mean I don't have to re-implement much when I do the migration.
From what I know Spring and JBoss AS play nicely together. I wouldn't expect you would need to re-implement much, but I'm not a Spring expert by any stretch. Your mileage may vary.
When using spring, the application context is generally started from a servlet once for the lifetime of the web application.
The servlet specification strongly discourages the creation of application threads for various reasons (see spec 3.0 1.2, 126.96.36.199, 2.3.4, 188.8.131.52, A.5.3).
For instance, 1.2 summarize the general idea:
A servlet container may place security restrictions on the environment in which a
servlet executes. In a Java Platform, Standard Edition (J2SE, v.1.3 or above) or Java
Platform, Enterprise Edition (Java EE, v.1.3 or above) environment, these restrictions
should be placed using the permission architecture defined by the Java platform. For
example, high-end application servers may limit the creation of a Thread object to
insure that other components of the container are not negatively impacted.
But the reality is that most application servers do not stricly enforce this contract and if you are careful you can create and use a pool of threads.
There are many ways to do parallel work.
It really depends on the kind of framework you must deal with.
You could have to stay with the bounds set by JEE and use JMS + MDB only.
You could use asynchronous web services.
You could create a thread pool in you spring context and use it for parallel work.
Another variation could be to use spring-integration and a splitter / aggragator + thread executor for parallel processing.
(see for instance http://java.dzone.com/articles/spring-integration-splitter)
The pragmatic view on this is that whenever you create yourself a thread:
a) You are operating outside the requirements of JEE specs
b) You should try to use JEE mecanisms (like JMS + MBD)
c) In real life, most if not all application servers will not enforce the rule
d) You can create a thread pool but you use the help of a framework such as spring or spring-integration