kapok

          垃圾桶,嘿嘿,我藏的這么深你們還能找到啊,真牛!

            BlogJava :: 首頁 :: 新隨筆 :: 聯(lián)系 :: 聚合  :: 管理 ::
            455 隨筆 :: 0 文章 :: 76 評論 :: 0 Trackbacks
          The Hibernate Session implements transparent write behind. Changes to the domain
          model made in the scope of a Session aren’t immediately propagated to the database.
          This allows Hibernate to coalesce many changes into a minimal number of
          database requests, helping minimize the impact of network latency.
          For example, if a single property of an object is changed twice in the same
          Transaction, Hibernate only needs to execute one SQL UPDATE. Another example
          of the usefulness of transparent write behind is that Hibernate can take
          advantage of the JDBC batch API when executing multiple UPDATE, INSERT, or
          DELETE statements.
          Hibernate flushes occur only at the following times:
          ■ When a Transaction is committed
          ■ Sometimes before a query is executed
          ■ When the application calls Session.flush() explicitly

          Flushing the Session state to the database at the end of a database transaction is
          required in order to make the changes durable and is the common case. Hibernate
          doesn’t flush before every query. However, if there are changes held in memory that
          would affect the results of the query, Hibernate will, by default, synchronize first.
          You can control this behavior by explicitly setting the Hibernate FlushMode via a
          call to session.setFlushMode(). The flush modes are as follows:
          ■ FlushMode.AUTO—The default. Enables the behavior just described.
          ■ FlushMode.COMMIT—Specifies that the session won’t be flushed before query
          execution (it will be flushed only at the end of the database transaction). Be
          aware that this setting may expose you to stale data: modifications you made
          to objects only in memory may conflict with the results of the query.
          ■ FlushMode.NEVER—Lets you specify that only explicit calls to flush() result
          in synchronization of session state with the database.
          We don’t recommend that you change this setting from the default.(OpenSessionInview需要仔細(xì)考慮) It’s provided
          to allow performance optimization in rare cases. Likewise, most applications rarely
          need to call flush() explicitly. This functionality is useful when you’re working
          with triggers, mixing Hibernate with direct JDBC, or working with buggy JDBC drivers.
          You should be aware of the option but not necessarily look out for use cases.
          Now that you understand the basic usage of database transactions with the
          Hibernate Transaction interface, let’s turn our attention more closely to the subject
          of concurrent data access.
          It seems as though you shouldn’t have to care about transaction isolation—the
          term implies that something either is or is not isolated. This is misleading. Complete
          isolation of concurrent transactions is extremely expensive in terms of application
          scalability, so databases provide several degrees of isolation. For most applications,
          incomplete transaction isolation is acceptable. It’s important to understand the
          degree of isolation you should choose for an application that uses Hibernate and
          how Hibernate integrates with the transaction capabilities of the database.
          posted on 2005-05-30 16:09 笨笨 閱讀(1274) 評論(1)  編輯  收藏 所屬分類: J2EEHibernateAndSpringALL

          評論

          # re: Hibernate FlushMode 2008-06-12 15:50 往往
          怎末不翻譯啊?  回復(fù)  更多評論
            

          主站蜘蛛池模板: 吉首市| 托克逊县| 盐山县| 庄浪县| 仲巴县| 米脂县| 巴中市| 安达市| 巴彦淖尔市| 湄潭县| 双峰县| 两当县| 灌阳县| 历史| 嫩江县| 西峡县| 延津县| 巴青县| 会理县| 辉县市| 灯塔市| 香河县| 双柏县| 平果县| 贵定县| 定日县| 台北县| 稻城县| 铅山县| 涪陵区| 仪陇县| 扶风县| 威宁| 甘德县| 新建县| 新余市| 葵青区| 湖北省| 许昌县| 吉木乃县| 昌乐县|