[ http://issues.apache.org/jira/browse/DERBY-941?page=comments#action_12374888 ]
Anurag Shekhar commented on DERBY-941: -------------------------------------- Statement Event Listener is expected to be used by Statement pooling. Nothing stops a regular application of add use this but section 11.7 hints about it. My understanding is that the statement pool will use this even to drop the statement from the pool and there won't be any question of the invalid statement being used again. In case it does most probably its a faulty implementation of pooling. The spec and api says the even should be raised when the driver detects the statment is invalid and before throwing the exception. I don't see why it can't be thrown twise. Your 2nd point its quite interresting doe that scenario ment the statement was never invalid ? > 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: 10.0.2.0 > 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: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
