db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Lance J. Andersen" <Lance.Ander...@Sun.COM>
Subject Re: [jira] Commented: (DERBY-941) Add JDBC4 support for Statement Events
Date Wed, 19 Apr 2006 13:11:52 GMT


Knut Anders Hatlen (JIRA) wrote:
>     [ 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.
>
>   
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.
>> 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.
>>     
>
>   

Mime
View raw message