| Subject | Re: [Firebird-Java] Events |
|---|---|
| Author | Jim Starkey |
| Post date | 2005-02-10T22:45:52Z |
Roman Rokytskyy wrote:
go anyplace else with JDBC. I'm inclined to think that connection
pooling is an ugly bandaid over problem that is going to get worse with
time, 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.
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?
The wire protocol only supports isc_que_events, which I guess answers
your question.
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.
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.
'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.
--
Jim Starkey
Netfrastructure, Inc.
978 526-1376
>There are two issues to solve: one is technical (see below) about how to getTruth, justice, and motherhood.
>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 am not inclined to extend the java.sql.Connection interface with eventIt belongs naturally on the Connection object. In fact, it can't really
>concept as it neither fits JCA architecture nor JDBC connection pooling.
>
>
go anyplace else with JDBC. I'm inclined to think that connection
pooling is an ugly bandaid over problem that is going to get worse with
time, 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.
>Is there some reason that the JDBC guys don't give names to things?
>
>>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.
>
>
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?
The wire protocol only supports isc_que_events, which I guess answers
your question.
>>You will want to put a certain amount of intelligence in that layer toThe event mechanism is based on named events (names are ascii strings)
>>simplify the handling of multiple events.
>>
>>
>
>Jim, can you elaborate on this? What intelligence and multiple events do you
>mean?
>
>
>
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.
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.
'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.
--
Jim Starkey
Netfrastructure, Inc.
978 526-1376