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

Yes, that was my idea to have a shared event manager. I must admit that my
main design goal is an event manager that can be directly used in EJB
applications. As I wrote before, main idea is that event manager just
publishes the messages into JMS queue or topic. The issue you have described
with the monopolizing callback thread can be avoided by using multiple
threads and a thread pool (similar to the way web servers handle client
requests).

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

That depends on the implementation. There are two ways to wrap the original
connection - a statically coded proxy implementing the java.sql.Connection
interface and a dynamic proxies (java.lang.reflect.Proxy). Former does not
provide anything except the java.sql.Connection interface, latter allows
specifying the list of interfaces to implement. JayBird uses latter approach
for javax.sql.DataSource/XADataSource/ConnectionPoolDataSource
implementations. That means that each connection object obtained from our
pool can be safely casted to FirebirdConnection interface.

If we configure a datasource for J2EE server, we cannot be sure that it does
not use statically coded proxies. However we have much bigger problems here
than accessing custom code - if we want our client code conform the EJB
specification we have to live with a fact that lifetime of our client code
is controlled by the EJB container. Container can decide to "passivate" the
EJB component (in other words, save its state into persistent storage and
reuse instance for something else). Event callbacks simply do not fit this
concept. The only possible way to invoke the client code is to create a
so-called message-driven bean that is invoked when a message is published
into the JMS queue or topic. In this case container will initiate new
transaction and call our client in the context of that transaction. So, for
the J2EE world that is the only possible solution to the problem - we have
to have at least one event manager per J2EE server.

Regarding the "normal" or "rich" clients - they can use either direct access
to the java.sql.Connection object or they can use our pool. The worst thing
I see here is the fact that if they want to listen to events, they have to
open a connection on session start and close it when session ends. This is
not so tragic, and maybe many people use connections exactly this way (I
don't - I allocate connection right before use and close it right after
use).

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

In most cases - wrapper. But again, most of my code I write for J2EE
applications, so that's one view on the problem. I need input from other
side too :)

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

Seriously, I think Sun was just too lazy to enforce usage of
human-understandable types - not everybody knows what type 1 driver means,
but JDBC-ODBC bridge says a lot.

I think you're right, we should update our documentation to use better
names.

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

It is always hard to talk to someone who had invented many things - you
never know what that person did not invented. :)

>> Thanks!
>>
>>
> For the explanation or the feature?

Both.

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

I'm thinking about your proposal to java.sql.Connection, but at present I
prefer a separate shared event manager. Also I would like to hear ideas of
other users about the usage scenarios.

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

That's a pity, since the concept is great and it would simplify many
applications if it were available in most databases. How long Borland is
going to own the patent? It is 15 years or 25 totally?

Roman