> Before you decide how to procede, you need to think a bit about how you
> want your events delivered. If you want everything event client to
> start it's down listener thread, the isc_event_wait is probably the way
> to do. If you want to handle single listener thread for all clients,
> then isc_que_events is the way to go. My guess is that having each
> event client start a listener thread is the way to go.

There are two issues to solve: one is technical (see below) about how to get
events in Java and one is conceptual - make event concept fit the
JDBC/JCA/J2EE concepts nicely or propose an extension of those concepts.

I would also think of the separate listener thread per client. In case of
the J2EE environment is able to post events to JMS queue or topic. Also
there should be a way to get events in Java application without JMS.

I am not inclined to extend the java.sql.Connection interface with event
concept as it neither fits JCA architecture nor JDBC connection pooling.

> You will probably want to have a Java layer to construct and deconstruct
> event blocks and make very thin JNI calls.

I see event support as an extension of the org.firebirdsql.gds.GDS
interface. Design must fit both type 2 and type 4 JDBC drivers. Both wire
protocol implementation as well as JNI implementation should provide same
result to the upper layers. Whether that are separate objects or simply byte
arrays is implementation issue, though I would prefer that to be
objects/interfaces.

> You will want to put a certain amount of intelligence in that layer to
> simplify the handling of multiple events.

Jim, can you elaborate on this? What intelligence and multiple events do you
mean?

Roman