Browse Prior Art Database

Java Asyncronous Method Execution Facility

IP.com Disclosure Number: IPCOM000022690D
Original Publication Date: 2004-Mar-25
Included in the Prior Art Database: 2004-Mar-25
Document File: 3 page(s) / 63K

Publishing Venue

IBM

Abstract

Disclosed is a Java Asynchronous Method Execution System. It is a programmatic component that programmers can use when they wish to perform execution of a specific method on a specific Java class asynchronously , and/or repeatedly. Unike other solutions, our system does require that the classes be modified in order to be asynchronously executed.

This text was extracted from a PDF file.
At least one non-text object (such as an image or picture) has been suppressed.
This is the abbreviated version, containing approximately 52% of the total text.

Page 1 of 3

Java Asyncronous Method Execution Facility

The invention addresses the need to execute Java methods asynchronously or repeatedly. This can be useful for consolidating (and delaying) database transactions, keeping in-memory caches up to date by periodically polling data sources, etc. The invoking application will need to identify the method that needs to be executed, the object instance on which the method is to be called, the arguments (if any), the expected return code, the time of the execution, whether or not the method is to be called repeatedly, and how many times the invocation is to be re-tried if it fails. The system relies on the Java reflection mechanism in order to gain access to methods of a given object. The invoked methods would have to be made public for this to work.

The description below refers to an implementation of the idea. It is illustrated in a diagram at the bottom of this document.

In order to use the system, the application developer instantiates the Task object with all pertinent information (when the task should be executed, type of task (repetitive or not), number of retries, the name of the method to call, the parameters, the object the method should be called on, the correct return object, etc.) This Task object is then submitted to the TaskContainer class, which adds it to the system.

The diagram below illustrates a typical life cycle of a Task. Thread objects are shown as ovals, while the queues and tasks are rectangular.

If the TaskContainer determines that the Task object passed to it is not marked for immediate execution, it adds it to the Unscheduled queue. The Scheduler thread is notified of this event. It examines the Task object and based on its contents, calculates the time when it needs to be executed. It then moves it in the Scheduled queue. (We should note that all queues are based on the first in- first out principle)

The Scheduled queue is polled on a periodic basis by the Activator thread. The Activator goes through the list of all tasks and identifies the ones that are due to be executed. These are moved to the...