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

[Sanne Grinovero]

Hi Gail,
thanks for checking all that!

And sure I won't delete it out of the blue in a micro, I'd deprecate
it first, make a JIRA for removal later, etc etc but first I'd like to
hear if someone would prefer me to stay away and leave it there: while
I'm failing to see a good reason for this method to exist I guess
someone could know better.

Thanks

On Fri, 16 Aug 2019 at 21:24, Gail Badner <gbadner at redhat.com> wrote:
>
> 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