[
http://issues.apache.org/jira/browse/DERBY-941?page=comments#action_12374933 ]
V.Narayanan commented on DERBY-941:
-----------------------------------
Hi,
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
Narayanan
> 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
