Subject | Re: [Firebird-Java] Events |
---|---|
Author | Gabriel Reid |
Post date | 2005-10-12T19:01:20Z |
On Wed, Oct 12, 2005 at 01:28:54PM -0400, Rick Debay wrote:
// -------------------------------------------------------------
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
}
interface EventListener {
void eventOccurred(DatabaseEvent event);
}
interface DatabaseEvent {
int getEventCount();
String getEventName();
}
// -------------------------------------------------------------
The waitForEvent methods of EventManager return the number of events
that occurred while waiting. This, as well as the getEventCount method
of DatabaseEvent, are a due to the fact that if a large number of events
occur in a short time in the database, only a single notification will
be sent, although the actual count is available.
In terms of implementation, the FBEventManager connects to a database
independently of JDBC objects, in the same style as the
xxxManager classes in the org.firebirdsql.management package. One
FBEventManager is required per database that is to be listened to,
although it is possible to use multiple FBEventManagers per database.
In testing, I've found that the notifications always seem to come
through within a second, usually a lot less, and I haven't been able to
force any missed deliveries, although the time between when the event
manager starts to connect to the database and when the events actually
start coming through seems to be somewhat variable (within a few
seconds), depending on how stressed the DB server is. I also must add
that all testing up to this point has been done on a single machine
(running Linux), so my experiences should not be used as any kind of
solid reference just yet.
Any questions, comments or suggestions about any of this are very
welcome.
Gabriel
> Is there any documentation that I could look at in order to startThe relevant parts of the relevant interfaces are as follows:
> 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.
>
> As an aside, this is a great topic for evangelism, as it really
> simplifies the glue in the application stack.
// -------------------------------------------------------------
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
}
interface EventListener {
void eventOccurred(DatabaseEvent event);
}
interface DatabaseEvent {
int getEventCount();
String getEventName();
}
// -------------------------------------------------------------
The waitForEvent methods of EventManager return the number of events
that occurred while waiting. This, as well as the getEventCount method
of DatabaseEvent, are a due to the fact that if a large number of events
occur in a short time in the database, only a single notification will
be sent, although the actual count is available.
In terms of implementation, the FBEventManager connects to a database
independently of JDBC objects, in the same style as the
xxxManager classes in the org.firebirdsql.management package. One
FBEventManager is required per database that is to be listened to,
although it is possible to use multiple FBEventManagers per database.
In testing, I've found that the notifications always seem to come
through within a second, usually a lot less, and I haven't been able to
force any missed deliveries, although the time between when the event
manager starts to connect to the database and when the events actually
start coming through seems to be somewhat variable (within a few
seconds), depending on how stressed the DB server is. I also must add
that all testing up to this point has been done on a single machine
(running Linux), so my experiences should not be used as any kind of
solid reference just yet.
Any questions, comments or suggestions about any of this are very
welcome.
Gabriel