[hibernate-dev] API removal proposal: org.hibernate.resource.jdbc.ResourceRegistry#cancelLastQuery

[Gail Badner]

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 at hibernate.org>
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 at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>