What are the benefits of using
ThreadWorks?
Benefits to developers:
· Easy to learn and use
· Provides pre-built infrastructure and tuning support to help troubleshoot.
· Allows you to concentrate on application issues, not threading concerns.
· Allows you to control and configure bandwidth allocated to asynchronous or batch tasks.
· Completely scalable with your application.
Benefits to businesses:
· Makes multi-threading capabilities available to junior developers as well as senior staff.
· Scales with your applications.
· Reduces number and severity of outages due to threading issues.
Can I use ThreadWorks
in an EJB Container such as Weblogic or WebSphere?
A qualified Yes; multi-threading is a technical violation of the EJB specification. Beans aren’t supposed to spawn threads. Having said this, many EJB containers don’t enforce this restriction and do allow multi-threading. However, there is always a risk that containers might enforce this rule someday. Because of this risk, we recommend that you use Threadworks from within RMI services instead of enterprise beans. ThreadWorks can be run in an RMI services without issue. Most (if not all) EJB containers include support for RMI Services.
Threadworks has been tested in Weblogic, WebSphere, and several other containers.
What types or applications
are best-suited to ThreadWorks?
We see ThreadWorks as a complementary product to application servers (such as Weblogic or WebSprere) and CORBA object request brokers (ORBs such as Visibroker or Orbix). Application servers and ORBs manage user load very well. ThreadWorks helps you manage tasks that are no longer associated with a user’s session or are maintenance tasks.
Doesn’t threading come with the
JDK? Why do we need ThreadWorks?
Threading does come with the JDK. The decision to use ThreadWorks is like any other build vs.buy decision. Many organizations leave developers to their own devices when it comes to threading. As a result, they are more vulnerable to classic threading problems, such as deadlock conditions, race conditions, and thread starvation conditions. They also have no consistent way to identify and tune asynchronous tasks on their application server or ORB. They are also more vulnerable to load problems as their asynchronous task load increases.
Another choice would be to develop coding standards regarding thread use and enforce them throughout the organization. Most standards enforcement efforts are at least partially successful. Another choice would be to build a counter-part to ThreadWorks. This can work well, but you need to budget for support and maintenance.
Are their advantages to using
ThreadWorks’ Scheduler over java.util.Timer?
For those that aren’t familiar, java.util.Timer was added to Java in V1.3.0. Timer has a subset of the ThreadWorks’ Scheduler capabilities. Timer will perform one-time executions of tasks at a specific time. As Timer manages one background Thread, any run-away task scheduled through it can keep other scheduled tasks from running. Also, if you need to schedule a recurring task, you need to write that logic yourself. Also, Timer doesn’t have non-time based dependency support as ThreadWorks’ Scheduler does.
As ThreadWorks’ Scheduler manages a TaskManager, you benefit from all the infrastructure and tuning support that TaskManager provides. Also, ThreadWorks’ Scheduler, unlike Timer, can scale with your application.
© Delta Vortex Technologies, Inc.; 2001. All Rights Reserved.