jdbcTemplate معلقة على تحديث طويل

Question

وأنا تحولت في الآونة الأخيرة إلى إطار الربيع بدلا من التعامل مع JDBC يدويا، وأنها في الغالب انتقال جيد. بدأ برنامج واحد تواجه مشاكل غريبة، على الرغم من: إذا كانت قاعدة البيانات بطيئة، عند استدعاء getJdbcTemplate().update( ... ) في بعض الأحيان يعود أبدا

.

وبعد البحث قليلا، وأنا حولت من طراز أباتشي DBCP إلى C3PO ، ولكن المشكلة لا تزال عاد.

وهنا هو رمز أنا باستخدام:

public class MyDao extends SimpleJdbcDaoSupport {
    private static Logger logger = Logger.getLogger(MyDao.class);

    public MyDao(Config config) {
        super();

        ComboPooledDataSource cpds = new ComboPooledDataSource();
        try {
            cpds.setDriverClass("com.mysql.jdbc.Driver");
        } catch (PropertyVetoException e) {
            throw new RuntimeException(e);
        }
        cpds.setUser("username");
        cpds.setPassword("password");
        cpds.setJdbcUrl("jdbc:mysql://localhost/schema" + 
                        "?useUnicode=true&characterEncoding=UTF-8");
        cpds.setMaxStatements( 180 );
        cpds.setPreferredTestQuery("SELECT 1");
        cpds.setTestConnectionOnCheckout(true);

        this.setDataSource(cpds);
    }

    public void addToWorkQueue(String item) {
        long[] ids = Utils.getItemIds(item);

        try {
            logger.debug("About to insert to work table");
            getJdbcTemplate().update(
                    "INSERT IGNORE INTO work " +
                    "SELECT * FROM queue WHERE id_1 = ? AND id_2 = ?",
                    new Object[] { ids[0], ids[1] }
            );
        } finally {
            logger.debug("Updated work table");
        }
    }
}

وإليك ما يبدو في ملف السجل:

2009-07-29 17:37:13.570 com.mycomp.MyDao About to insert into work table
2009-07-29 17:37:13.570 com.mchange.v2.c3p0.impl.C3P0PooledConnectionPool Testing PooledConnection [com.mchange.v2.c3p0.impl.NewPooledConnection@170984c] on CHECKOUT.
2009-07-29 17:37:13.571 com.mchange.v2.c3p0.stmt.GooGooStatementCache checkinAll(): com.mchange.v2.c3p0.stmt.GlobalMaxOnlyStatementCache stats -- total size: 1; checked out: 0; num connections: 1; num keys: 1
2009-07-29 17:37:13.571 com.mchange.v2.c3p0.impl.C3P0PooledConnectionPool Test of PooledConnection [com.mchange.v2.c3p0.impl.NewPooledConnection@170984c] on CHECKOUT has SUCCEEDED.
2009-07-29 17:37:13.571 com.mchange.v2.resourcepool.BasicResourcePool trace com.mchange.v2.resourcepool.BasicResourcePool@d402dd [managed: 3, unused: 2, excluded: 0] (e.g. com.mchange.v2.c3p0.impl.NewPooledConnection@170984c)
2009-07-29 17:37:13.571 com.mchange.v2.c3p0.stmt.GooGooStatementCache com.mchange.v2.c3p0.stmt.GlobalMaxOnlyStatementCache ----> CACHE HIT
2009-07-29 17:37:13.571 com.mchange.v2.c3p0.stmt.GooGooStatementCache checkoutStatement: com.mchange.v2.c3p0.stmt.GlobalMaxOnlyStatementCache stats -- total size: 1; checked out: 1; num connections: 1; num keys: 1

وهذا هو المكان الذي توقف التعليمات البرمجية. وعادة ما يذهب فقط على مثل هذا:

2009-07-29 17:37:13.762 com.mchange.v2.c3p0.stmt.GooGooStatementCache checkinStatement(): com.mchange.v2.c3p0.stmt.GlobalMaxOnlyStatementCache stats -- total size: 1; checked out: 0; num connections: 1; num keys: 1
2009-07-29 17:37:13.763 com.mchange.v2.c3p0.stmt.GooGooStatementCache checkinAll(): com.mchange.v2.c3p0.stmt.GlobalMaxOnlyStatementCache stats -- total size: 1; checked out: 0; num connections: 1; num keys: 1
2009-07-29 17:37:13.763 com.mchange.v2.resourcepool.BasicResourcePool trace com.mchange.v2.resourcepool.BasicResourcePool@d402dd [managed: 3, unused: 2, excluded: 0] (e.g. com.mchange.v2.c3p0.impl.NewPooledConnection@170984c)
2009-07-29 17:37:13.763 com.mycomp.MyDao Updated work table

وأنا لا أعرف لماذا أنا لا تحصل على أي رسالة سجل من إطار الربيع نفسها. وأضفت هذه السطور في قانون بلدي الرئيسي:

Logger springLogger = Logger.getLogger("org.springframework");
springLogger.setLevel(Level.TRACE);
springLogger.debug("testing spring logger");

وتظهر رسالة اختبار، ولكن أي شيء آخر. آسف لمتباينة.

وفعلت لاحظت وجود تباطؤ من قبل على تعليق. آخر مرة ركض الاستعلام بنجاح أنه استغرق مدة دقيقة ونصف حتى النهاية، بدلا من 200MS المعتادة. في المرة القادمة، واسمحوا لي أن تشغيل لمدة 25 دقيقة قبل أن يقتل في العملية.

وأنا أعرف أن لدي بعض المشاكل مع قاعدة البيانات الخاصة بي (ك InnoDB)، وأنا أعمل على، ولكن هذا يبدو وكأنه بعد مهلة، إطار الربيع فقط "يتخلى" وتوقف.

وسيكون موضع تقدير أي نصيحة.

Answer 1

وأخيرا، تم تفادي المشكلة عن طريق إصلاح المشكلة DB الأساسية.

وكنت تستخدم InnoDB الجدول إلى قائمة انتظار العمل، مما يعني أضفت وإزالة مجموعة كبيرة من الأدوات لذلك. أبدا زيارتها الجدول صفوف كثيرة جدا في وقت معين، ولكن يبدو ك InnoDB لا يمكن التعامل مع هذا النوع من العمل، أو كما قال لي صديق DBA ذلك "، وحذف الصفوف من الجدول لا تفعل أي شيء للحصول على أداء".

وبعد التحول إلى استراتيجية ديسيبل جنونا من ذلك بكثير، والذي ينطوي إنشاء وحذف الجداول في كل وقت، وكان الأداء تحسن كثيرا وتوقف ذهب بعيدا.

وهكذا أعتقد أن ما أقوله هو، كان تعليق skaffman في الصحيح على الأرجح. وهذا لا يكون لها أي علاقة مع الربيع.