实施的解决方案最终看起来像这样：

一般的想法是维护当前正在运行的查询的所有Hibernate会话到发起它们的用户的HttpSession的映射，这样，当用户关闭浏览器时，我们将能够杀死正在运行的查询。

这里要克服两个主要挑战。一种是将HTTP会话ID从Web层传播到EJB层，而不会干扰沿途的所有方法调用-
即不篡改系统中的现有代码。第二个挑战是弄清楚一旦数据库已经开始返回结果并且Hibernate用结果填充对象，如何取消查询。

根据我们的认识，第一个问题得以克服，因为我们意识到沿着堆栈调用的所有方法都由同一线程处理。这很有意义，因为我们的应用程序全部存在于一个容器中，并且没有任何远程调用。在这种情况下，我们创建了一个Servlet过滤器来拦截对应用程序的每次调用，并添加ThreadLocal带有当前HTTP会话ID
的变量。这样，HTTP会话ID将可沿行的每个方法调用使用。

第二个挑战是更具粘性。我们发现，负责运行查询并随后填充POJO的Hibernate方法已被调用doQuery并位于org.hibernate.loader.Loader.java该类中。（我们碰巧使用的是Hibernate
3.5.3，但对于较新版本的Hibernate也是如此。）：

private List doQuery(
        final SessionImplementor session,
        final QueryParameters queryParameters,
        final boolean returnProxies) throws SQLException, HibernateException {

    final RowSelection selection = queryParameters.getRowSelection();
    final int maxRows = hasMaxRows( selection ) ?
            selection.getMaxRows().intValue() :
            Integer.MAX_VALUE;

    final int entitySpan = getEntityPersisters().length;

    final ArrayList hydratedObjects = entitySpan == 0 ? null : new ArrayList( entitySpan * 10 );
    final PreparedStatement st = prepareQueryStatement( queryParameters, false, session );
    final ResultSet rs = getResultSet( st, queryParameters.hasAutoDiscoverScalarTypes(), queryParameters.isCallable(), selection, session );

    final EntityKey optionalObjectKey = getOptionalObjectKey( queryParameters, session );
    final LockMode[] lockModesArray = getLockModes( queryParameters.getLockOptions() );
    final boolean createSubselects = isSubselectLoadingEnabled();
    final List subselectResultKeys = createSubselects ? new ArrayList() : null;
    final List results = new ArrayList();

    try {

        handleEmptyCollections( queryParameters.getCollectionKeys(), rs, session );

        EntityKey[] keys = new EntityKey[entitySpan]; //we can reuse it for each row

        if ( log.isTraceEnabled() ) log.trace( "processing result set" );

        int count;
        for ( count = 0; count < maxRows && rs.next(); count++ ) {

            if ( log.isTraceEnabled() ) log.debug("result set row: " + count);

            Object result = getRowFromResultSet( 
                    rs,
                    session,
                    queryParameters,
                    lockModesArray,
                    optionalObjectKey,
                    hydratedObjects,
                    keys,
                    returnProxies 
            );
            results.add( result );

            if ( createSubselects ) {
                subselectResultKeys.add(keys);
                keys = new EntityKey[entitySpan]; //can't reuse in this case
            }

        }

        if ( log.isTraceEnabled() ) {
            log.trace( "done processing result set (" + count + " rows)" );
        }

    }
    finally {
        session.getBatcher().closeQueryStatement( st, rs );
    }

    initializeEntitiesAndCollections( hydratedObjects, rs, session, queryParameters.isReadOnly( session ) );

    if ( createSubselects ) createSubselects( subselectResultKeys, queryParameters, session );

    return results; //getResultList(results);

}

在此方法中，您可以看到，首先以老式的形式从数据库中获取结果java.sql.ResultSet，然后在每个集合上循环运行并从中创建一个对象。initializeEntitiesAndCollections()在循环之后调用的方法中执行一些其他初始化。经过一点调试之后，我们发现大部分性能开销都在方法的这些部分中，而不是在java.sql.ResultSet从数据库中获取的部分中，但是该cancelQuery方法仅在第一部分有效。因此，解决方案是在for循环中添加一个附加条件，以检查线程是否被中断，如下所示：

for ( count = 0; count < maxRows && rs.next() && !currentThread.isInterrupted(); count++ ) {
// ...
}

以及在调用initializeEntitiesAndCollections()方法之前执行相同的检查：

if (!Thread.interrupted()) {

    initializeEntitiesAndCollections(hydratedObjects, rs, session,
                queryParameters.isReadOnly(session));
    if (createSubselects) {

        createSubselects(subselectResultKeys, queryParameters, session);
    }
}

另外，通过Thread.interrupted()在第二个检查中调用，该标志被清除，并且不影响程序的进一步功能。现在，当要取消查询时，取消方法将使用HTTP
session-id作为键访问Hibernate会话和存储在映射中的线程cancelQuery，在会话上调用该interrupt方法，然后调用该线程的方法。