db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "V.Narayanan (JIRA)" <derby-...@db.apache.org>
Subject [jira] Commented: (DERBY-941) Add JDBC4 support for Statement Events
Date Tue, 18 Apr 2006 13:22:20 GMT
    [ http://issues.apache.org/jira/browse/DERBY-941?page=comments#action_12374933 ] 

V.Narayanan commented on DERBY-941:

thanx for the comments!

1) In the example we are waiting for the affect of the Delete table operation to be undone
by the create operation before the PreparedStatement 
    becomes usable again. Is'nt this a special case where the DDL undoes the operation of
an earlier DDL? What if the create table did not happen at 
    all? Then would'nt the PreparedStatement remain invalid?

2)  There are two cases for this Error Occurred Event as I see it

      a) Assume that the ConnectionPoolManager which has registered itself to listen to statement
events is actually doing what is mentioned as part of   
           the javadoc comment (i.e.) creating a temporary table in this case it can catch
the error occurred event check the content to see the 
           PreparedStatement and also the SQLException object contained within the StatementEvent
(which would indicate the reason for occurrence 
           of the event) and if it occurred because of non-existence of the temporary table
ignore it.

        b) In the case that the ConnectionPoolManager has not created a temporary table and
it is a genuine case of a invalid PreparedStatement it needs
             to know it can make use of the error occurred event that is raised.
        Thus throwing a error occurred event would allow the ConnectionPoolManager to decide
what needs to happen


> Add JDBC4 support for Statement Events
> --------------------------------------
>          Key: DERBY-941
>          URL: http://issues.apache.org/jira/browse/DERBY-941
>      Project: Derby
>         Type: New Feature

>   Components: JDBC
>     Versions:
>     Reporter: Rick Hillegas
>     Assignee: V.Narayanan
>  Attachments: ListenerTest.java, statementeventlisteners_embedded.diff, statementeventlisteners_embedded.stat,
statementeventlisteners_embedded_v2.diff, statementeventlisteners_embedded_v2.stat, statementeventlisteners_embedded_ver1.html
> As described in the JDBC 4 spec, sections 11.2, 11.7,  and 3.1.
> These are the methods which let app servers listen for connection and statement closure
and invalidation events.
> Section 11.2 of the JDBC 4 spec explains connection events: Connection pool managers
which implement the ConnectionEventListener interface can register themselves to listen for
 "connectionClosed" and fatal "connectionErrorOccurred" events. App servers can use these
events to help them manage the recycling of connections back to the connection pool.
> Section 11.7 of the JDBC 4 spec explains statement events: Statement pools which implement
StatementEventListener can register themselves to listen for "statementClosed" and "statementErrorOccurred"
events. Again, this helps statement pools manage the recycling of statements back to the pool.

This message is automatically generated by JIRA.
If you think it was sent incorrectly contact one of the administrators:
For more information on JIRA, see:

View raw message