[hibernate-dev] API removal proposal: org.hibernate.resource.jdbc.ResourceRegistry#cancelLastQuery
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@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
Re: [hibernate-dev] API removal proposal: org.hibernate.resource.jdbc.ResourceRegistry#cancelLastQuery
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 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@lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev > ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
Re: [hibernate-dev] API removal proposal: org.hibernate.resource.jdbc.ResourceRegistry#cancelLastQuery
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 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 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@lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/hibernate-dev ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
