Why use a manager?
Why are EJB and GUI application so successful? Because they run inside a container; a framework that manages persistence, messaging, thread management, logging, the event queue, the user interface and much more.
A Backend Server doesn't have a similar application container to manage queues, threads, messaging, logging and more.
Developers who construct backend applications know that it is first necessary to build a framework in which the application lives.
[ need more details? ]
[ need meticulous details? ]-- Essence --
Application Threads | Parallelism | Persistence | Recursion | Debugging, Recovery, Tuning | Overall Picture
Two common uses for application threads on a Backend Server are the timing of requests and the autonomous request, with or without callback.
Timing:
When timing a request, the Client thread cannot time itself. If it gets caught in a long or never ending loop then it may not be able to break out of the code when the time expires. Therefore, it is necessary for the Client thread to start a new application thread. The Client thread may time the new thread and if the time expires the request does not complete.
This seems simple enough. However, there are serious problems with this approach.
For every request there is a new application thread. The VM must create and destroy every thread. This overhead puts a severe strain on resources. There may come a time when the VM cannot sustain any more threads and the entire VM becomes unusable.
[Some developers may put the timing code in the client. Rather than have a standard timing mechanism on the server, each client application must add proprietary timing code.]
What happens to the threads that time-out? If there is problem with a resource that the threads require before completing, then, once again, there may come a time when the VM cannot sustain any more threads and the entire VM becomes unusable.
[Even with the timing code in the client, the Client threads still hang.]
Autonomous requests:
The only way to schedule this background task is to start a new application thread and inform the client that the request is pending.
Again, this seems simple enough. Again, there are serious problems with this approach.
The thread overload problem is the same as with the timed request, above.
The thread stall problem, as above, is even more serious. Since there is no time-out, the clients never know there is a problem.
Clients waiting for a notification need a way to inquire of the status of their request.
To handle these problems one must manage the application environment.
- There must be a thread-limit parameter to avoid thread overload. There should be a queuing mechanism with thread initiation according to load, not chance.
- There must be a way to notify clients before the situation gets out of control.
- There must be a way to dynamically alter the parameters as business needs change.
Tymeac is that manager.
Parallelism:
Often a request requires more than a simple compute or fetch from a resource. The request may need several methods. For linear programming, one method simply follows the other. However, by making each method a thread, one may take advantage of multi-programming and multi-processing capable machines.
Creating a thread for each method in Java™ is very easy.
However, all the problems with threads mentioned above are relevant here as well. In addition, the Client thread must now monitor multiple application threads and concatenate any return values from these threads for the client.
To handle these problems one must design a full-feature application manager.
Tymeac is that manager.
Persistence:
Could you use connection pools for your JDBC work thereby saving cycles and memory? Could you use common storage to keep track of how many messages are outstanding within a Message Queuing start/stop sequence? Could you use common storage as a work area between threads?
Managing the common variables including how threads access and update that storage requires a great deal of time and effort outside the pure application development area.
To handle persistent storage properly one must manage the Backend Server environment.
Tymeac is that manager.
Recursion:
When the current process itself requires another asynchronous process, the effort required in keeping track of allocated storage, time-out, back-out, etc., means that designers usually chose some other, less efficient method.
To handle recursion one must manage the entire application environment.
Tymeac is that manager.
Debugging:
How does one trap the application thread when one doesn't know which thread is currently handling this request? There is always trial and error. There is always println(). There is always setting a breakpoint at the beginning of the code and walking all the way through.
Recovery:
Recovery assumes that one is in control of the situation, catches the exception, backs-out valuable resources and restores the proper state. Without a proper management facility, the assumption is false.
Tuning:
Tuning starts with designing for tuning. Without tuning as a prime thought in the design phase, there is no tuning in the execution stage. Throwing hardware at the problem, (E.G. adding more memory, more file space, etc.), only works for a while.
To handle these problems requires a total management package.
Tymeac is that manager.
Picture:
What is the status of an autonomous request? What requests are stalled? What is the current thread load? How many requests are currently backed up? Can we get a "snap shot" of the overall queuing environment usage? Is there a log? Etc.
Building these pictures requires so much effort on the part of the development team that it overshadows the service it is meant to serve.
Tymeac is a manager that provides logging and statistics as well as dozens of GUI and non-GUI classes to give administrators not only a picture of the environment but the means to alter that environment.
