db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Knut Anders Hatlen (JIRA)" <derby-...@db.apache.org>
Subject [jira] Commented: (DERBY-941) Add JDBC4 support for Statement Events
Date Wed, 19 Apr 2006 12:12:19 GMT
    [ 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 happen

Again, 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.  Narayanan

No, 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 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


Mime
View raw message