Real World Examples

Contents

Basic
Thresholds
Hot Requests
Timing Requests
Asynchronous Requests
Flood and Ebb
Intermediate Back-out
Multiple Requests
Recursion
Failure Containment
Parallel Processing
Gateway
The Agent
Call-Back/Forward

Basic Backend Processing

An application needs to place a request in a queue and have it processed in the background.

Problem

Setting up a prioritized queue, other than a simple vector, means a lot of code. Putting the request in and taking it out are easy, but reorganizing, browsing (with GUI's) and error recovery take a lot of time. Then there is the thread -- a multitude of things can go wrong there and every exception means more code.

Solution

Set up a Tymeac^™ Queue with one or more threads^.*

All the classes to handle prioritized queues, multi-threading and GUI's are already built.

Thresholds

An application on the Backend Server has components that use a proprietary DBMS.

Problem

Each DBMS connection can only handle one request at a time but there are multiple connections available for each DBMS. By using several connections simultaneously, throughput can be greatly increased.

Solution

Set up a Tymeac^™ Queue with multiple threads^* for each component. Tymeac^™ supports four thresholds to activate a thread:^*

1. When the number of outstanding requests in all wait lists exceeds an amount.
2. When the number of outstanding requests in an individual wait list exceeds an amount.
3. When the number of outstanding requests in an individual wait list plus a weighted factor exceeds an amount.
4. When the number of outstanding requests in the average of all wait lists plus a weighted factor and considering the number of currently executing threads^* exceeds an amount.

As the load on a Queue exceeds a threshold, Tymeac^™ creates a new thread^* to balance the load.

Hot Request

An application uses the backend process to schedule work on a document storing system.

Problem

Most of the time the processing is a FIFO. However, the 'hot' request needs to head queue.

Solution

Set up a Tymeac^™ Queue with prioritized wait lists. The Tymeac^™ Function normally places the request into wait list two (normal priority). When a high priority document enters the system, simply use priority one. The Tymeac^™ Function places the request into waitlist one and the Queue Thread^* picks it up before the other requests.

Timing Requests

An application needs a service but can only wait three seconds for a response.

Problem

Timing sounds easy; when the time limit expires, end the unit of work. Building timing into each service is a lot of work. Each thread^* of execution must interrupt its work to see if it is over the time limit. Additionally, some accesses use blocking and there is no way to break out of the blocking until the access is complete.

Solution

Tymeac^™ supports timing as a standard feature. All services in Tymeac^™ are with application threads^*. Therefore, whether the application thread^* is blocking or not is irrelevant.

Asynchronous (autonomous) Requests

An application simply needs to log the result of processing. It isn't always practical to stop, do the log and then continue. The application just wants to push the request off to a background process to do the logging.

Problem

Each "push" requires a new thread^* to process the request. Eventually the System runs out of threads^* or the thread^* create/destroy overhead bogs down all the processing.

Solution

Tymeac^™ supports autonomous processing as a standard feature. Set up a single Tymeac^™ Queue with one or two threads^*. Push the request into this Queue and let Tymeac^™ manage the processing.

Flood and Ebb

A company's call centers are spread out over four time zones.

Problem

At 0730 local time each call center logs into headquarters to establish communication and at 2030 local time the call center logs out. This results in a flood of activity but only for a few minutes in the morning and evening in each time zone. (E.G. at 0730 time zone one floods; at 0830 time zone two floods, etc.)  Thereafter, the activity is on an "as needed" basis.

Solution

Tymeac^™ supports thread^* creation/destruction on an as needed basis. You simply specify the maximum number of threads^* each Queue needs, when to create the thread^* (at Tymeac^™ startup or when first needed) and how long to keep the thread^* alive when the activity wanes (a few seconds or forever).

In this way, as each time zone floods headquarters with activity, there are sufficient threads^* to process the requests. When the active period is over, the threads^* cease as well.

Intermediate Back-out

An application is binary -- all components of the request succeed or the request is a failure.

Problem

Sometimes a component of the request does not schedule because the wait lists are full for that component or there are no threads^* available, etc. In this binary scenario when one component does not schedule, then the request is a failure. Cancel this request at the earliest possible time.

Solution

Tymeac^™ supports intermediate back-out as a standard feature. Un-scheduling the other components not only gets the response back to the client sooner it cuts down on processor cycles.

Multiple Requests

An application has a need to access several proprietary systems: data base, message queuing and networking. All these systems are all able to process many request from many sources simultaneously.

Problem

An application must "connect" to each of these systems. When the application finishes the instant request, it must "disconnect" from each system. This connect/disconnect results in a huge overhead.

Solution

Tymeac^™ supports common user storage (persistent shared storage) as a standard feature. Within this common storage users may place counts of how many requests may pass to a sub-system before a disconnect, users may keep connection pools and any other utilities necessary to control access to proprietary systems.

Recursion

A shop sets up a standard application that notifies a set of users when there is a new document in the system that may be of interest to them.

Problem

The notifying should be done in an asynchronous manner without the direct knowledge of each application. We don't want each application to include a class for this notify.

Solution

Tymeac^™ supports recursive calls as a standard feature. Tymeac^™ passes the reference to itself to every processing application class so that application may call the Tymeac^™ Server as a client. Set up the notify as a Tymeac^™ Function. Any application that needs to notify users simply calls the Tymeac^™ Server with a new Function. All the work is handled asynchronously.

Failure Containment

An imaging application comprises access to three data bases to store an image in three formats. Each component has no relationship to the other components, it is completely independent.

Problem

Independent components have unique requirements for error recovery. Generally, when one part of a request fails it has an affect on the other parts and severely complicates recovery. The more components, the bigger the mess.

Solution

Tymeac^™ Queues are completely independent of each other. Each processing application may do anything in any way without affecting any other application. If one imaging access fails, the error recovery logic is contained within only that application.

Parallel Processing

When a customer calls customer service, he needs a wide range of information from many sources. The customer service GUI is basically very simple: each pane has the information from a source.

Problem

The application must get this information from many different sources: file, DBMS etc. With a serial approach, the next access cannot start until the current access is complete. This results in long response times even for the panels where the information is local.

Solution

Parallel processing in Tymeac^™ is standard. Set up a Tymeac^™ Queue with one thread^* for each component. A Tymeac^™ Function places the request into each of these Queues. Since the processing is in parallel, as each processing application finishes, its information is available for display.

Gateway

Similarly to the multiple requests and failure containment above, this application needs access to legacy systems that are not part of the base system.

Problem

An application must "get access" to each of these systems through the a Native Interface. Any failure here certainly means the destruction of the thread^* and possible corruption of the immediate environment.

Solution

Tymeac^™ supports any type of application. Tymeac^™ has automated error recovery as well as manual error recovery when human intervention is necessary. Part of the manual recovery gives you the ability to terminate unresponsive threads^* and create new threads^* for each Queue.

The Agent

This application has multiple components that pass information to other systems. However, some of those systems pass back receipts and depending on the results, further action may need to be taken.

Problem

There are a huge number of requests and no reply is necessary for the requester. Some of the components need load balancing (number of threads^* processing) while others need to process multiple requests between an open/close sequence (networking and message queuing systems). Additionally, some Queues need a synchronous access to other systems to wait for the receipt and need to make decisions depending on the outcome.

Solution

Set up a Tymeac^™ Queue with multiple threads^* for each component and an output Agent. A Tymeac^™ Function places the request into each of these Queues. The processing is parallel. Tymeac^™ balances the thread^* load in each Queue with thresholds. By using Tymeac^™ common storage, threads^* within a queue may keep track of how many requests process between the open/close sequence.

When the last Queue finishes processing, Tymeac^™ activates the output Agent. This Agent may parse the results of the other Queues and take any further action when needed.

Call-Back/Forward

This application has multiple components that pass information to other systems and some of those systems pass back receipts and depending on the results, further action needs to be taken. That action is a network request to a remote system when all went well or a callback to the requester when there is an anomaly.

Problem

There are a huge number of requests and no reply MAY BE necessary for the requester. Some of the components need load balancing (number of threads^* processing) while others need to process multiple requests between an open/close sequence (networking and message queuing systems). Additionally, some Queues need a synchronous access to other systems to wait for the receipt and need to make decisions depending on the outcome.

When the outcome is normal, the application passes a message to a remote system. When the outcome is abnormal, the application passes a message back to the requester.

Solution

Set up a Tymeac^™ Queue with multiple threads^* for each component and an output Agent. A Tymeac^™ Function places the request into each of these Queues. The processing is parallel. Tymeac^™ balances the thread^* load in each Queue with thresholds. By using Tymeac^™ common storage, threads^* within a queue may keep track of how many requests process between the open/close sequence.

When the last Queue finishes processing, Tymeac^™ activates the output Agent. This Agent parses the results of the other Queues and uses a (Remote) Procedure Call  to pass the outcome either to the remote system (call-forward) or to back to the requester (call-back).

^* These are asynchronous tasks for the CICS® version.