使用连接池(本地或实例)的网站的连接对象范围

发布于 2024-08-20 12:55:27 字数 1526 浏览 5 评论 0原文

对于启用了连接轮询的 Web 应用程序,使用本地范围的连接对象还是实例范围的连接对象更好?我知道两者之间可能没有很大的性能改进(因为池化),但是你会说一个比另一个遵循更好的模式吗?谢谢;)

public class MyServlet extends HttpServlet {
    DataSource ds;

    public void init() throws ServletException {
        ds = (DataSource) getServletContext().getAttribute("DBCPool");
    }

    protected void doGet(HttpServletRequest arg0, HttpServletResponse arg1) throws ServletException, IOException {
        SomeWork("SELECT * FROM A");
        SomeWork("SELECT * FROM B");
    }

    void SomeWork(String sql) {
        Connection conn = null;
        try {
            conn = ds.getConnection();
            // execute some sql
            .....
        } finally {
            if(conn != null) {
                conn.close(); // return to pool
            }
        }
    }
}

或者

public class MyServlet extends HttpServlet {
    DataSource ds;
    Connection conn;*

    public void init() throws ServletException {
        ds = (DataSource) getServletContext().getAttribute("DBCPool");
    }

    protected void doGet(HttpServletRequest arg0, HttpServletResponse arg1) throws ServletException, IOException {
        try {
            conn = ds.getConnection();
            SomeWork("SELECT * FROM A");
            SomeWork("SELECT * FROM B");
        } finally {
            if(conn != null) {
                conn.close(); // return to pool
            }
        }
    }

    void SomeWork(String sql) {
        // execute some sql
        .....
    }
}

For a web application with connection polling enabled, is it better to work with a locally scoped connection object or instance scoped connection object. I know there is probably not a big performance improvement between the two (because of the pooling) but would you say that one follows a better pattern than the other. Thanks ;)

public class MyServlet extends HttpServlet {
    DataSource ds;

    public void init() throws ServletException {
        ds = (DataSource) getServletContext().getAttribute("DBCPool");
    }

    protected void doGet(HttpServletRequest arg0, HttpServletResponse arg1) throws ServletException, IOException {
        SomeWork("SELECT * FROM A");
        SomeWork("SELECT * FROM B");
    }

    void SomeWork(String sql) {
        Connection conn = null;
        try {
            conn = ds.getConnection();
            // execute some sql
            .....
        } finally {
            if(conn != null) {
                conn.close(); // return to pool
            }
        }
    }
}

Or

public class MyServlet extends HttpServlet {
    DataSource ds;
    Connection conn;*

    public void init() throws ServletException {
        ds = (DataSource) getServletContext().getAttribute("DBCPool");
    }

    protected void doGet(HttpServletRequest arg0, HttpServletResponse arg1) throws ServletException, IOException {
        try {
            conn = ds.getConnection();
            SomeWork("SELECT * FROM A");
            SomeWork("SELECT * FROM B");
        } finally {
            if(conn != null) {
                conn.close(); // return to pool
            }
        }
    }

    void SomeWork(String sql) {
        // execute some sql
        .....
    }
}

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(1

优雅的叶子 2024-08-27 12:55:27

您应该采用这种方法:

  1. 从池中获取连接
  2. 执行完整的事务,将数据库从一个有效状态移动到下一个
  3. 提交
  4. 将连接返回到池
  5. 返回 HTTP 响应

您的第一种方法不是一个好主意,因为如果工作单元失败可能会使数据库处于不一致的状态。

也许您将完成第一个工作单元,然后无法获取第二个池连接(其他一些线程首先进入)。也许在重负载下,多个请求都会发生这种情况,并且什么都无法正确完成。

You should take this approach:

  1. Take a connection from the pool
  2. Conduct a complete transaction, moving the database from one valid state to the next
  3. Commit
  4. Return the connection to the pool
  5. Return the HTTP response

Your first approach is not a good idea because if one of the units of work fails you may leave the database in an inconsistant state.

Perhaps you will complete the first unit of work and then be unable to take the second pool connection (some other thread got in first). Maybe under heavy load, this will happen to multiple requests and nothing will get done properly.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文