java - 我应该在调用 session.evict(obj) 之前提交 hibernate 事务吗

Question

我应该在什么时候在保存后在 hibernate 中提交事务。是在调用 session.evict(obj) 之前还是之后。目前我的代码看起来像这样(只有必需的部分)。

Session session = connector.getSession();
Transaction tx = session.beginTransaction();
try {
        Criteria crit = session.createCriteria(ST_CODE_SETTINGS_STORE.class).add(Restrictions.eq("TYPE", "issueno"));
        List<ST_CODE_SETTINGS_STORE> ls = crit.list();
        if (ls.size() < 1) {
            session.save(st_code_settings_store);
            session.evict(st_code_settings_store);
            msg = "insert";
        } 
        else {
            Long Id = null;
            ST_CODE_SETTINGS_STORE st_code_settings_store1 = ls.get(0);
            Id = st_code_settings_store1.getCODE_ID();

            Object o = session.get(ST_CODE_SETTINGS_STORE.class, Id);
            ST_CODE_SETTINGS_STORE update = (ST_CODE_SETTINGS_STORE) o;
            session.update(update);
        }
        tx.commit();
    } catch (Exception e) {
        if (tx != null) {
            tx.rollback();
        }
        System.out.println("Error: " + e.getMessage());
        connector.printStack(e);
        throw e;
    } finally {
        session.close();
    }

有时如果我在驱逐后提交，数据不会保存在数据库中。这是正确的编码方式吗？？

Answer 1

The method evict() removes a single object from Session cache. Sobefore you call evict() the object should be there in the Sessioncache. Therefore if you save the object first time, you have to savethe object via Session.save(object). Subsequent update calls shouldfollow through session.saveOrUpdate(object) or session.update(object)before calling evict() to remove the loaded object from the cache.(reference )

From Hibernate Docs

Ending a Session usually involves four distinct phases:

• flush the session
• commit the transaction
• close the session
• handle exceptions

Do not use the anti-patterns session-per-user-session orsession-per-application (there are, however, rare exceptions to thisrule). Some of the following issues might also arise within therecommended patterns, so ensure that you understand the implicationsbefore making a design decision:

• A Session is not thread-safe. Things that work concurrently, like HTTPrequests, session beans, or Swing workers, will cause race conditionsif a Session instance is shared. If you keep your Hibernate Session inyour HttpSession (this is discussed later in the chapter), you shouldconsider synchronizing access to your Http session. Otherwise, a userthat clicks reload fast enough can use the same Session in twoconcurrently running threads.

• An exception thrown by Hibernate meansyou have to rollback your database transaction and close the Sessionimmediately (this is discussed in more detail later in the chapter).If your Session is bound to the application, you have to stop theapplication. Rolling back the database transaction does not put yourbusiness objects back into the state they were at the start of thetransaction. This means that the database state and the businessobjects will be out of sync. Usually this is not a problem, becauseexceptions are not recoverable and you will have to start over afterrollback anyway.

• The Session caches every object that is in apersistent state (watched and checked for dirty state by Hibernate).If you keep it open for a long time or simply load too much data, itwill grow endlessly until you get an OutOfMemoryException. Onesolution is to call clear() and evict() to manage the Session cache,but you should consider a Stored Procedure if you need mass dataoperations.