[ 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.
