Mailing-List: contact derby-dev-help@db.apache.org; run by ezmlm
Precedence: bulk
Reply-To: <derby-dev@db.apache.org>
Message-ID: <28487567.1145366540081.JavaMail.jira@brutus>
Date: Tue, 18 Apr 2006 13:22:20 +0000 (GMT+00:00)
From: "V.Narayanan (JIRA)" <derby-dev@db.apache.org>
To: derby-dev@db.apache.org
Subject: [jira] Commented: (DERBY-941) Add JDBC4 support for Statement
 Events
In-Reply-To: <847461104.1139600944980.JavaMail.jira@ajax.apache.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit

    [ 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