Knut Anders Hatlen (JIRA) wrote: Your milage is going to vary as to what/when the statement is invalid. A lot will depend on the backend which is why the wording is not crystal clear with details.[ http://issues.apache.org/jira/browse/DERBY-941?page=comments#action_12375102 ]Knut Anders Hatlen commented on DERBY-941: ------------------------------------------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?Maybe. It's probably a special case that the table is dropped and the statement is re-executed too, but it's still a case...What if the create table did not happen at all? Then would'nt the PreparedStatement remain invalid?That depends on how "invalid" is defined, but the way I read the javadoc for StatementEventListener, it is seems like the spec considers the statement as valid, since it is not necessarily unusable in the future. 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.In that case, the connection pool manager needs knowledge about how the tables are used and whether the database invalidates statements on DDL operations. I don't think we can expect the manager to have such knowledge.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 happenAgain, I don't think the connection pool manager has enough information to decide this. It is the application that creates and accesses the table. The manager just does what the application tells it to do, and it has no way to find out whether the application will recreate the table later.We are throwing the error occurred event only upon doing an execute on the PreparedStatement. If the ConnectionPoolManager did know that the temporary table or the table used in the PreparedStatement or in the generalized case knew of a DDL invalidating a PreparedStatement why would it do a execute on the PreparedStatement? Does'nt this qualify as a faulty Pooling implementation? If it were using a temporary table it would do an execute only during the time that the temporary table exists. NarayananNo, I don't think this means the pool manager is faulty. It is the application, not the manager, that decides when it invokes execute().Add JDBC4 support for Statement Events -------------------------------------- Key: DERBY-941 URL: http://issues.apache.org/jira/browse/DERBY-941 Project: Derby Type: New FeatureComponents: 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. |
- [jira] Commented: (DERBY-941) Add JDBC4 support ... V.Narayanan (JIRA)
- [jira] Commented: (DERBY-941) Add JDBC4 support ... Rick Hillegas (JIRA)
- [jira] Commented: (DERBY-941) Add JDBC4 support ... Rick Hillegas (JIRA)
- [jira] Commented: (DERBY-941) Add JDBC4 support ... V.Narayanan (JIRA)
- [jira] Commented: (DERBY-941) Add JDBC4 support ... Rick Hillegas (JIRA)
- [jira] Commented: (DERBY-941) Add JDBC4 support ... Anurag Shekhar (JIRA)
- [jira] Commented: (DERBY-941) Add JDBC4 support ... Knut Anders Hatlen (JIRA)
- [jira] Commented: (DERBY-941) Add JDBC4 support ... V.Narayanan (JIRA)
- [jira] Commented: (DERBY-941) Add JDBC4 support ... V.Narayanan (JIRA)
- [jira] Commented: (DERBY-941) Add JDBC4 support ... Knut Anders Hatlen (JIRA)
- Re: [jira] Commented: (DERBY-941) Add JDBC4... Lance J. Andersen
- Re: [jira] Commented: (DERBY-941) Add J... V.Narayanan
- [jira] Commented: (DERBY-941) Add JDBC4 support ... V.Narayanan (JIRA)
- [jira] Commented: (DERBY-941) Add JDBC4 support ... Knut Anders Hatlen (JIRA)
- [jira] Commented: (DERBY-941) Add JDBC4 support ... V.Narayanan (JIRA)
- [jira] Commented: (DERBY-941) Add JDBC4 support ... Knut Anders Hatlen (JIRA)
- [jira] Commented: (DERBY-941) Add JDBC4 support ... Knut Anders Hatlen (JIRA)
- [jira] Commented: (DERBY-941) Add JDBC4 support ... V.Narayanan (JIRA)
- [jira] Commented: (DERBY-941) Add JDBC4 support ... Knut Anders Hatlen (JIRA)
- [jira] Commented: (DERBY-941) Add JDBC4 support ... Knut Anders Hatlen (JIRA)
- [jira] Commented: (DERBY-941) Add JDBC4 support ... V.Narayanan (JIRA)