Jim,

> It belongs naturally on the Connection object. In fact, it can't really
> go anyplace else with JDBC.

How is event listening related to transaction associated with the connection
object? What happens if transaction is committed? I suspect nothing. Events
need a separate socket connection, the only thing they need are credentials.
Events are not relly related to a connection, since they notify about things
done by others, not by yourself.

So, it can also be viewed as a complete separate part of the driver.
Something called FBEventManager.

> I'm inclined to think that connection pooling is an ugly bandaid over
> problem that is going to get worse with time,

You like it or not, but it is there, most J2EE servers use connection
pooling, a lot of applications rely on connection pooling by using following
pattern:

Connection connection = dataSource.getConnection();
try {
...
} finally {
connection.close();
}

And, even more, as long as you stay within one J2EE container-manager
transaction, all connections will be part of that transaction. Without
connection pooling you cannot achieve that.

> I'd rather see it as clean extension to the JDBC interfaces. At least,
> that's the way I would do it. If you have to use connection pooling, and
> connection pooling hides the actual Jaybird Connection object, I guess
> you're stuck.

Or you use a stand-alone event manager. In case of J2EE application that
event manager posts events to JMS queue or topic, in "plain old JDBC" it
calls a callback.

> Is there some reason that the JDBC guys don't give names to things?
> TLAs are bad enough, but driver types named after numbers are screwy.
> Do they have to be ordinal? Could we have a type pi driver?

Well, that's established convention. If you invent "type pi" driver, you can
use that name too.

> The wire protocol only supports isc_que_events, which I guess answers
> your question.

Yup. Then this is the first task to implement.

> The event mechanism is based on named events (names are ascii strings)
> and event counts. The mechanism is designed so any application can wait
> on any number of events, get notification as multiple events on a single
> callback, and never lose events due to race conditions. The database
> event manager associates an event count with every interesting event.
> What a client is really doing is sending a set of <event, threshold>
> pairs asked to be notified if if/when the event count of any named event
> exceeds the threshold. If so, the event manager returns the current
> event count associated with each named event. By convention, the
> conversation starts with the client asking for all events with a
> threshold of zero, which returns immediately. After the first call, the
> client event code must compare the event thresholds it passed in with
> updates counts coming back to find out what events actually fired. What
> the application does then is highly application specific.

Thanks!

> A event management class needs to track event counts, construct event
> blocks, compare event blocks to determine what events actually fired,
> and tell the application that something happened.

So, you're not yet convinced for a standalone event management class? :)

> 'Twere it I designing the sucker, I'd define a notification interface.
> A client could give the event management class a set of event names and
> objects implementing that interface to be called when the named event
> fired. Application code doesn't want to even hear about event counts.

Exactly. And that is quite a lot of code to do, and the only thing it shares
with connection object are credentials - use name and password; it does not
need charset, numeber of DPB buffers, or even role. Sorry, but for me that
is clear indication that it does not have almost anything in common with
Connection object.

Roman