> V.Narayanan commented on
> 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
> 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().