Gabriel Reid wrote:

> On Wed, Oct 12, 2005 at 01:28:54PM -0400, Rick Debay wrote:
> > Is there any documentation that I could look at in order to start
> > architecting for this? It'll really simplify our system design (ex
> > generation of invoice has JMS run report) and decouple a lot of things.
> > But the devil is always in the details and I want to make sure we
> > understand all the issues (guaranteed delivery, etc) upfront.
>
> The relevant parts of the relevant interfaces are as follows:
>
> // -------------------------------------------------------------
>
> interface EventManager {
>
> void addEventListener(String eventName, EventListener listener);
>
> void removeEventListener(String eventName, EventListener listener);
>
> int waitForEvent(String eventName);
> throws InterruptedException;
>
> int waitForEvent(String eventName, int timeout)
> throws InterruptedException;
>
> void connect();
>
> void disconnect();
>
> // Getters and setters for connection info not shown
> }
>

You should understand that these interfaces won't handle multiple events
or return event counts that allow the application to detect multiple
postings.

The actual Firebird event call is isc_que_events, containing a database
handle, and event block, and a callback routine. The format of the
event block is:

<version> { <counted event name> <event threshold> }...

The callback is called asynchronously when any count associated with a
named event reaches the threshold given. The callback is passed an
updated event block with each threshold set to the current event count +
1. It is normally called with zero thresholds for initialization, which
completes immediately with the initial threshold values.

I'm not at all sure that an event interface built around single events
is all that useful. If I were doing it, I'd want to ability to block on
one of any number of events and the ability to get a callback from a
dedicated listening thread.

--

Jim Starkey
Netfrastructure, Inc.
978 526-1376