Hi,
We're looking at removing or making the use of CancelPreparedStatement
configurable. Would anybody have a concern with this? If you have no idea
what I am referring to, then you are probably not affected and you can quit
reading. But, if you even know what the CancelPreparedStatement wrapper
is, you should probably continue reading and offer your input. Thanks!
With every SQL PreparedStatement, OpenJPA wrappers each one in a
CancelPreparedStatement wrapper. From the javadoc:
/**
* Statement type that adds and removes itself from the set of active
* statements so that it can be canceled.
*/
So, on every Statement execution, OpenJPA does some before and after
processing which adds and removes the Statement from a Set, respectively.
This processing would allow some external utility to gain access to this
Set (via a xxxStoreManager.cancelAll) and supposedly cancel any Statements
which may be in the process of being executed.
OpenJPA itself does not take advantage of this capability. It looks like
this was put in for some external processing or extension that I am not
aware of.
So, the question is does anybody know of current usage of this
xxxStoreManager.cancelAll() method and, thus indirectly, the
CancelPreparedStatement wrapper? To save on these "wasted" cycles, I'd
like to make this capability configurable. Since we have so many
configuration options already in OpenJPA, I'm wondering which direction to
make the default action. Should I remove the use of
CancelPreparedStatement and make this the default (since I'm not aware of
any usage and the default would be better performing), or should I leave
the default as currently configured and force a new configuration property
to get the better performance?
Comments and suggestions are welcome.
Thanks,
Kevin
