java SpringHibernate在webapp中使用，线程安全会话管理的策略是什么

Question

我正在用Spring和Hibernate开发一个web应用程序，我痴迷于使应用程序线程安全并能够支持重载，因此根据我老板的建议，我最终编写了自己的session和session container来实现session per request pattern。加上我有很多{}我不愿意为所有的{}写同样的{}我复制粘贴这个{a1}（我不能说这是同一件事，因为当时hibernate不是jboss所有）和做管道的东西，在压力下，所有这些都很快变得复杂并投入生产，这是过时的ObjectException和重复的数据，我觉得是时候回顾一下我所做的工作了，简化它，并使它在处理大型数据时更加健壮。您应该知道的一件事是，一个请求涉及多个DAO

正在运行quartz以获取数据库中的某些更新

虽然我想把一切都调整得更好，但我没有时间做必要的研究，加上Hibernate是一种巨大的学习

就这样，我想借用你们的经验，问几个问题，知道该走什么方向

问题1：Hibernate生成的uuid对于线程环境和避免StaleObjectException足够安全吗

问题2在threadSafe场景中使用hibernate getCurrentSession的最佳策略是什么（我已经阅读了threadlocal的内容，但没有得到太多的理解，所以没有这么做）

问题3：HIbernateTemplate是否可以作为最简单的解决方案

问题4：如果要实现生产服务器的连接池和调优要求，您将选择什么

请毫不犹豫地向我指出博客或在线资源，我所需要的只是一种适合我的场景的方法。如果你要这样做，你的方法

谢谢你读到这篇文章，欢迎大家的意见

Answer 1

I'm developing a web app with Spring and Hibernate and I was so obsessed by making he application thread safe and being able to support heavy load that based on my boss recommendation I end up writing my own session and a session container to implement a session per request pattern.

您应该删除所有这些代码，改用Spring/HibernateAPI：更少的bug，更少的维护

I copy paste this Hibernate GenericDAO (I can't tell it's the same thing because at the time hibernate wasn't owned by jboss) and do the plumbing stuff, and under pressure, all become quickly complicated (...)

您可以使用GenericDao并使用Spring注入所需的内容

Question 1: is Hibernate generated uuid safe enough for threading environment and avoiding StaleObjectException?

为了严格回答您的问题，以下是参考指南中有关uuid生成器的内容：

5.1.4.1. Generator

...

• uuid

  uses a 128-bit UUID algorithm to generate identifiers of type string that are unique within a network (the IP address is used). The UUID is encoded as a string of 32 hexadecimal digits in length.

所以我认为这是安全的。但是我认为你的StaleObjectException是不相关的（这是另一个问题）

Question 2: what are best strategy to use hibernate getCurrentSession in threadSafe scenario (I've read about threadlocal stuff but didn't get too much understanding so didn't do it)

最好的策略是使用它，sessionFactory.getCurrentSession()将始终为当前数据库事务提供一个Session作用域，也称为“上下文会话”。再次引用参考文件：

2.5. Contextual sessions

Most applications using Hibernate need some form of "contextual" session, where a given session is in effect throughout the scope of a given context. However, across applications the definition of what constitutes a context is typically different; different contexts define different scopes to the notion of current. Applications using Hibernate prior to version 3.0 tended to utilize either home-grown ThreadLocal-based contextual sessions, helper classes such as HibernateUtil, or utilized third-party frameworks, such as Spring or Pico, which provided proxy/interception-based contextual sessions.

(...)

However, as of version 3.1, the processing behind SessionFactory.getCurrentSession() is now pluggable. To that end, a new extension interface, org.hibernate.context.CurrentSessionContext, and a new configuration parameter, hibernate.current_session_context_class, have been added to allow pluggability of the scope and context of defining current sessions.

See the Javadocs for the org.hibernate.context.CurrentSessionContext interface for a detailed discussion of its contract. It defines a single method, currentSession(), by which the implementation is responsible for tracking the current contextual session. Out-of-the-box, Hibernate comes with three implementations of this interface:

• org.hibernate.context.JTASessionContext: current sessions are tracked and scoped by a JTA transaction. The processing here is exactly the same as in the older JTA-only approach. See the Javadocs for details.
• org.hibernate.context.ThreadLocalSessionContext: current sessions are tracked by thread of execution. See the Javadocs for details.
• org.hibernate.context.ManagedSessionContext: current sessions are tracked by thread of execution. However, you are responsible to bind and unbind a Session instance with static methods on this class: it does not open, flush, or close a Session.

(...)

现在没有必要实现自己的基于^{}的解决方案，不要这样做

Question 3 : will HIbernateTemplate do for the simplest solution approach?

嗯，HibernateTemplate并没有被弃用，但它不再被推荐，我更喜欢实现template-less DAOs：

public class ProductDaoImpl implements ProductDao {

    private SessionFactory sessionFactory;

    public void setSessionFactory(SessionFactory sessionFactory) {
        this.sessionFactory = sessionFactory;
    }

    public Collection loadProductsByCategory(String category) {
        return this.sessionFactory.getCurrentSession()
                .createQuery("from test.Product product where product.category=?")
                .setParameter(0, category)
                .list();
    }
}

其中SessionFactory由Spring注入。我建议阅读So should you still use Spring's HibernateTemplate and/or JpaTemplate??以获得完整的背景资料，以及Spring文档中关于ORM数据访问的整个部分

Question 4 : what will be your choice if you were to implement a connection pool and tuning requirement for production server?

嗯。。。什么我永远不会实现我的连接池，而是使用来自应用服务器的连接池。也许你应该澄清这个问题

更新：在生产环境中，我不会使用Hibernate内置的连接池，而是将Hibernate配置为使用应用服务器提供的JNDI数据源（以及应用服务器连接池）。从文件中：

3.3. JDBC connections

...

Here is an example hibernate.properties file for an application server provided JNDI datasource:

hibernate.connection.datasource = java:/comp/env/jdbc/test
hibernate.transaction.factory_class = \
    org.hibernate.transaction.JTATransactionFactory
hibernate.transaction.manager_lookup_class = \
    org.hibernate.transaction.JBossTransactionManagerLookup
hibernate.dialect = org.hibernate.dialect.PostgreSQLDialect

JDBC connections obtained from a JNDI datasource will automatically participate in the container-managed transactions of the application server.