Tymeac User Exits

As with other general purpose tools, Tymeac cannot supply all the functionality one may wish to have. Therefore, we provide exits or hooks into which you may add your own functionality.

The way in which one may use persistent storage is only limited by imagination. This is a shared sub-pool of storage for use by multiple Tymeac User Functions. We provide several sample Classes to demonstrate how one might set this up.

Tymeac provides four exits.

At Tymeac start up.

A Stage One shut down exit.

A Stage Two shut down exit.

An exit just before final termination of the Server that you may use for embedded database shut down or anything else you like.

All the exits are lists of Classes that Tymeac instantiates.

Each Class must have a public constructor that takes no parameters.

No other methods are permitted, only the constructor.

Simply put all the code you want inside this constructor.

For names with URL's, see the naming and URL document.

public class TyDemoStartup1 {

    public TyDemoStartup1() {

        // add your code here
    }
}

Tymeac loads (findSystemClass()) and instantiates each Class in the list with the code (where "names" is a String array):

try {
    // load the class and get a new instance
    ClassLoader.loadClass(names[i]).newInstance();
}

Tymeac catches exceptions prints and logs the associated messages and continues.

All the exits execute within the main Tymeac system, not as separate threads, therefore, any code that "hangs" will naturally hang that part of Tymeac where it executes, (start up or shut down.) This is not a design flaw. One uses these exits to establish and terminate private sub-systems that run inside the Tymeac Server persistent storage. Failures starting or terminating these private sub-systems are fatal.

Start Up Exit

The start up exit is at the completion of the basic Tymeac environment build but before any RMI code when an RMI Server. The basic Tymeac environment is all the tables (queue, function, etc.) and threads (monitor, etc.) that Tymeac needs to execute. However, it is before instantiating the RMI Implementation Classes and interfacing with the Registries or ORB's (when necessary.)

Tymeac instantiates any Classes in the user start up list.

The Tymeac Server is not available at this time for Tymeac Functions (see Start up Functions in the following section.). In addition, the TymeacInfo Singleton class only has limited value at this time.

Start up Functions

The start up functions, although not part of the exit structure, are mentioned here since they logically group in this section.

Shut Down, Stage 1 Exit

The stage 1 shut down exit is at the beginning of the Tymeac shut down sequence. Shut down may be as a result of a user shut down request or from deactivation when executing as an Activatable Remote Object. First, Tymeac marks the System in shut down mode so that no new requests may process. Then Tymeac instantiates any Classes in the user stage 1 shut down list.

The Tymeac Server is available to currently executing threads, however, no new Tymeac Functions may initiate.

It is recommended that stage 1 be the place to gracefully shut down, or at least start to shut down, internal sub-systems created in the start-up classes.

How can this exit determine whether the shutdown is the result of a Tymeac shutRequest() or from deactivation when executing as an Activatable Remote Object?

The com.tymeac.base.TymeacInfo Singleton Class contains information on the currently executing Tymeac Server:

if (TymeacInfo.getInstance().getShutOrigin() == TymeacInfo.DEACTIVATION) {

// Shutting down because of deactivation

Shut Down, Stage 2 Exit

The stage 2 shut down exit is at the end of the Tymeac shut down sequence. This may be:

after all Queue Threads terminate, or

if all Queue Threads haven't terminated, when shut down with force was requested, or

when running as an Activatable Remote Object, immediately after the stage 1 shut down exit.

Tymeac instantiates any Classes in the user stage 2 shut down list.

The Tymeac Server is unavailable for starting new Tymeac Functions. If this is a shut-with-force shutdown, there may be Queue Threads alive. Interaction with any of these threads is unpredictable. This can happen when using internal sub-systems created in the start-up classes.

Tymeac shut down continues with statistics writing and logging.

Embedded Data Base Exit

Although this exit was designed for use with embedded databases, there is no reason you can't use it for anything else.

You specify the name of the class with a command line option -edbsd.

Tymeac instantiates this Class at the end of Tymeac shut down just before starting the shut down thread (when required.)

This is, after executing any optional, stage-2 shut down Classes and writing the system statistics. The result may print on the console window (it's your code to do that.) If your code hangs for any reason, then Tymeac will not start the shut down thread. This is the same condition as for user exits, see above.

Why not shut down Functions?

Shut down means just that -- stop processing and shut down the Server. There are start up functions since, after start up, the Server is available for processing.

If one needs to execute a Processing Application Class during shut down exit processing then it is a simple task. Tymeac uses reflection to execute these classes since Tymeac does not know the names of these classes at compile time. Since it is logical that you would know the name of the class at compile time, you may simply specify:

Object obj = MyClass.main(args[]).

The class is in the classpath for the Tymeac Server so there is no problem locating the class at execution time.

The args[] refers to an Object array. The first element is anything you may wish to pass to the method. The second element is a reference to the Tymeac Server RemoteObject (TymeacInterface). You may use the start up functions to place a reference to this in your persistent storage.

One may also front-end the Tymeac Shut Down function with a private shut down user Function.

Create a user function, MyShutDown. The Processing Application Class may do that which is necessary to terminate the private user environment.

The Processing Application Class may then recursively call the Tymeac Shut Down function:

(TymeacInterface)args[1].shutRequest();

See the sample code we provide for com.tymeac.serveruser.DemoRecur.java and com.tymeac.demo.client.TyDemoClient_Shutdown.java