Hi Sanne, I've confirmed that current versions of WildFly and EAP do not call that ResourceRegistry#cancelLastQuery. ResourceRegistry was introduced in 5.0. As of 5.0.16, cancelLastQuery() is not used by Hibernate ORM. At least as far back as 4.2, SessionImpl#cancelQuery called JdbcCoordinator#cancelLastQuery(), which deals with JdbcCoordinatorImpl#lastQuery (not ResourceRegistry#cancelLastQuery). I believe that an application could only reach ResourceRegistry through an SPI ; for example, via * SharedSessionContractImplementor.getJdbcCoordinator().getResourceRegistry (deprecated since 5.2); or *SharedSessionContractImplementor.getJdbcCoordinator().getLogicalConnection.getResourceRegistry(). My preference is to follow our normal process for removing an SPI. In general, we try not to remove SPIs within a minor release (e.g., 7.x). We normally deprecate the method in 7.x. The soonest we would remove it would be in 7.x+1. Regards, Gail On Fri, Aug 16, 2019 at 10:17 AM Sanne Grinovero <sanne(a)hibernate.org&gt; wrote: > > Hi all, > > is this method needed? > > - org.hibernate.resource.jdbc.ResourceRegistry#cancelLastQuery > > It seems undocumented, untested, and everything compiles just fine if > I just delete it - however it seems marked as API. > > But also, I suppose this should be invoked by a different thread as > the one actually running the query? Which would imply this > implementation would need to be threadsafe, but it's not. > > My primary reason to explore its removal though is that this method is > in the way of some optimisations I'd like to apply to this class, so > it would be quite useful for me to be able to remove it - assuming > that it's no longer of interest to anyone else. > > Thanks, > Sanne > _______________________________________________ > hibernate-dev mailing list > hibernate-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev