Roman Rokytskyy wrote:

>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.
>
>

Events and transactions are independent. Event declarations are cached
by the engine transaction object until after the transaction has
successfully commited, but the event manager itself knows nothing of
transactions.

Events are, of course, related to a connection. Your point is that a
second connection, using a different API, can be used for events. This
is correct. The question is whether this best meets the needs of
resource utilization and general cleanliness.

As you point out, the event mechanism needs a second socket. If you use
a second connection, this goes from two sockets to three. This could be
a problem on servers that are socket bound. You could get around this
trying to share a single event manager against all clients with the same
credentials (though, if the event manager blocked all other access to
the physical connection, different accounts could share an event
manager). This, however, introduces problems of user cross talk. The
practical problem is that one client's event callback could monopolize
the event manager's callback thread. Bad manners, yes, but that's life.

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

I rather like the model of a Connection.createEventManager() call. If
various Java connection pooling mechanism block access to the action
Connection object, then this is impossible, and a shame. I have always
like the idea that in JDBC you talk to the real objects, not somebody
else's buggy filter as in ODBC. But if you are saying that extensions
to JDBC objects are invisible to client code, there isn't much of a
question anymore.

>
>
>>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.
>
>

Is the Connection object that comes from dataSource.getConnection a real
connection or a wrapper?

>
>
>>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.
>
>

One, two, three, four, pi. I like it. If I invent two, can I call the
other "Tuesday".

Personally, I think that "blob" had longer legs than "datatype type
92". The other accepted term I was resposible for was the "klunk", the
100 nanosecond unit of VAX time. But no more VAXen, no more klunks -- a
good tradeoff, I think.

>
>
>>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!
>
>

For the explanation or the feature?

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

If you tell me that no alternative is possible, I'll have to throw in
the towel.

The astute reader may have noticed the missing obligatory reference to
events in Netfrastructure. There aren't any. Borland owns my patent on
the event mechanism and has licensed it only for open source Interbase.
So enjoy your events; I can't.

--

Jim Starkey
Netfrastructure, Inc.
978 526-1376