Yes I know. This change was initiated by me.
The prepared statements are unusable and should be thrown away and rebuild at this point.
But the application should not get any notice about this.
How to achieve this?
I thought it was you :-)
The exception sorter (the implementation that determines whether or not an exception was fatal or not) does not differentiate between connection or statement. Since the statements are per managed connection, errors on the connection or the statement will be reflected in the sorter and typically will require that the connection be destroyed.
Another way to think of it is that there is no such thing as a prepared statement being fatal, and not have it effect the underlying managed connection. So, I am not sure what you mean by
"But the application should not get any notice about this."
Perhaps if you could explain a bit more. Sorry if I am not understanding your intent.
If the reuse of a prepared statement fails because of this (tables or statistics for the tables used in the query have changed since prepare) the prepared statement should be thrown away first. JBoss should then try to create a new prepared statement then.
If this also fails, there seems to be a fatal error and the connection should be marked unusable.
The session bean uisng the entity bean with the unusable statement gets the Exception.
For informix error -710 a new prepare of the statement should succeed, and the session been using the using the entity bean get's nothing aboud this new prepare and can contiue in execution.
So, what you are saying is that in the case of Informix, the statement should be attempted twice? This can be accomplished via coding. There is nothing to prevent your code from catching the exception, evaluating the code, and attempting to execute the statement a second time.
JCA is agnostic in terms of DB exceptions, coding for this particular case would imply that we 'know' of a specific INFORMIX error and attempt to execute the query again.
Sorry, but it just doesn't seem to be a valid use case in this context.
I can rework the INFORMIX exception sorter to not fail in the case of this particular error, effectively putting it back the way it was. The connection would still be valid in this case allowing you to execute the statement again.