How it works

Tymeac™ Server runs under Java™ as a 100% pure application.

The two main Tymeac^™ elements are Queues and Functions.

Queues contain:

• The individual user-written application Classes that execute as Reflection invoked code from a thread. In this way application code is decoupled from the thread code. (see also FAQ, reflection)

• The prioritized Wait Lists of pending requests.

• The logical anchor points for threads with create/destroy options of:
  • Created at Tymeac^™ startup or
  • created when first required.
  • Destroyed after an idle period or
  • never destroyed.
    
    

• The threshold variables for activating a new thread.

Functions are:

Lists of Queues. By knowing the list of Queues associated with each request, Tymeac^™ is able to separate the request into its components.

---

The process:

• The Client application passes a request to Tymeac^™ to get the job done (a Tymeac^™ Function).

Communication between the user request and Tymeac^™ is through a reference to a remote object (RMI) or directly when using the Server internally.

• Tymeac^™ schedules the request on the Tymeac^™ Queues necessary to complete the job.

• A thread on each Queue uses Reflection to invoke the user-written application Class for the Queue.

• For synchronous requests, Tymeac^™ waits until all processing completes and returns the results of all the processes to the Client.

• For asynchronous requests, Tymeac^™ returns immediately to the Client. (This is sometimes known as autonomous, background or back-end processing.)

Optionally, when the last Queue Thread process completes, it schedules an Agent that may further process the results of all the prior processes or pass the results to the network. [ example ]

Balancing

Synchronous thread processing does not provide any control over the queue of requests, the ability to view the queue, or to change priority. Most importantly, there is no facility to control the number of threads active at any one time.

 Tymeac^™ provides designers the tools necessary to balance the thread load.

• Each Queue may have as many threads as are prudent and necessary as a maximum.

• When to activate a new thread is always the major issue. Tymeac^™ analyzes four thresholds to give designers almost unlimited control over this parameter for each Queue.  [ example ]

• User parameters control when to create a physical thread (at Tymeac^™ start up or when first needed) and when to destroy the physical thread (after an idle period or never.)

• Threshold and Wait List variables are alterable during execution providing a dynamic response to an ever changing environment.