91成人噜噜噜在线播放,激情久久av,精品中文一区

hibernate java 事务(转蝲用于学习)

心晴 — Fri, 24 Oct 2008 08:07:00 GMT

Hibernate 是对JDBC的轻量��对象��装�Q�Hibernate本��n是不具备Transaction处理功能的，Hibernate的Transaction实际上是底层的JDBC Transaction的封装，或者是JTA Transaction的封装，下面我们详细的分析：

Hibernate可以配置为JDBCTransaction或者是JTATransaction�Q�这取决于你在hibernate.properties中的配置:

#hibernate.transaction.factory_class net.sf.hibernate.transaction.JTATransactionFactory
#hibernate.transaction.factory_class net.sf.hibernate.transaction.JDBCTransactionFactory

如果你什么都不配�|�，默认情况下��用JDBCTransaction�Q�如果你配置为：

hibernate.transaction.factory_class net.sf.hibernate.transaction.JTATransactionFactory

��用JTATransaction

不管你准备让Hibernate使用JDBCTransaction�Q�还是JTATransaction�Q�我的忠告就是什么都不配�Q�将让它保持默认状态，如下�Q?

#hibernate.transaction.factory_class net.sf.hibernate.transaction.JTATransactionFactory
#hibernate.transaction.factory_class net.sf.hibernate.transaction.JDBCTransactionFactory

在下面的分析中我会给出原因�?

一、JDBC Transaction

看看使用JDBC Transaction的时候我们的代码例子�Q?

Session session = sf.openSession();
Transaction tx = session.beginTransactioin();
...
session.flush();
tx.commit();
session.close();

�q�是默认的情况，当你在代码中使用Hibernate的Transaction的时候实际上��是JDBCTransaction。那么JDBCTransaction�I�竟是什么东西呢�Q�来看看源代码就清楚了：

Hibernate2.0.3源代码中的类

net.sf.hibernate.transaction.JDBCTransaction:

public void begin() throws HibernateException {

...
if (toggleAutoCommit) session.connection().setAutoCommit(false);
...
}

�q�是启动Transaction的方法，看到 connection().setAutoCommit(false) 了吗�Q�是不是很熟悉？

再来�?

public void commit() throws HibernateException {
...
try {
if ( session.getFlushMode()!=FlushMode.NEVER ) session.flush();
try {
session.connection().commit();
committed = true;
}
...
toggleAutoCommit();
}

�q�是提交�Ҏ��Q�看到connection().commit() 了吗�Q�下面就不用我多说了�Q�这个类代码非常��单易懂，通过阅读使我们明白Hibernate的Transaction都在�q�了些什么？我现在把�?Hibernate写的例子��译成JDBC�Q�大家就一目了然了�Q?

Connection conn = ...; <--- session = sf.openSession();

conn.setAutoCommit(false); <--- tx = session.beginTransactioin();

... <--- ...

conn.commit(); <--- tx.commit(); (对应左边的两�?
conn.setAutoCommit(true);

conn.close(); <--- session.close();

看明白了吧，Hibernate的JDBCTransaction�Ҏ��是conn.commit而已�Q�根本毫无神�U�可�a��Q�只不过在Hibernate 中，Session打开的时候，��׃��自动conn.setAutoCommit(false)�Q�不像一般的JDBC�Q�默认都是true�Q�所以你最后不�?commit也没有关�p�，�׃��Hibernate已经把AutoCommit�l�关掉了�Q�所以用Hibernate的时候，你在�E�序中不�?Transaction的话�Q�数据库�Ҏ��没有反应�?br /> 如果你在EJB中��用Hibernate�Q�或者准备用JTA来管理跨Session的长事务�Q�那么就需要��用JTATransaction�Q�先看一个例子：

javax.transaction.UserTransaction tx = new InitialContext().lookup("javax.transaction.UserTransaction");

Session s1 = sf.openSession();
...
s1.flush();
s1.close();

...

Session s2 = sf.openSession();
...
s2.flush();
s2.close();

tx.commit();

�q�是标准的��用JTA的代码片断，Transaction是跨Session的，它的生命周期比Session要长。如果你在EJB中��?Hibernate�Q�那么是最��单不�q�的了，你什么Transaction代码�l�统都不要写了，直接在EJB的部�|�描�q�符上配�|�某某方法是否��用事务就可以了�?

现在我们来分析一下JTATransaction的源代码�Q?net.sf.hibernate.transaction.JTATransaction:

public void begin(InitialContext context, ...
...
ut = (UserTransaction) context.lookup(utName);
...

看清楚了吗？和我上面写的代码 tx = new Initial Context?().lookup("javax.transaction.UserTransaction"); 是不是完全一��P��

public void commit() ...
...
if (newTransaction) ut.commit();
...

JTATransaction的控制稍微复杂，不过仍然可以很清楚的看出来Hibernate是如何封装JTA的Transaction代码的�?

但是你现在是否看��C��什么问题？仔细想一下，Hibernate Transaction是从Session中获得的�Q�tx = session.beginTransaction()�Q�最后要先提交tx�Q�然后再session.close�Q�这完全�W�合JDBC�?Transaction的操作顺序，但是�q�个��序是和JTA的Transactioin操作��序��d��矛盾的！�Q�！ JTA是先启动Transaction�Q�然后启动Session�Q�关闭Session�Q�最后提交Transaction�Q�因此当你��用JTA�?Transaction的时候，那么��千万不要��用Hibernate的Transaction�Q�而是应该像我上面的JTA的代码片断那样��用才行�?

�ȝ��Q?
1、在JDBC上��用Hibernate

必须写上Hibernate Transaction代码�Q�否则数据库没有反应。此时Hibernate的Transaction��是Connection.commit而已

2、在JTA上��用Hibernate

写JTA的Transaction代码�Q�不要写Hibernate的Transaction代码�Q�否则程序会报错

3、在EJB上��用Hibernate

什么Transactioin代码都不要写�Q�在EJB的部�|�描�q�符里面配置

|---CMT(Container Managed Transaction)
|
|---BMT(Bean Managed Transaction)
|
|----JDBC Transaction
|
|----JTA Transaction

--------------------------------------------------------------------------------

提问�Q?

javax.transaction.UserTransaction tx = new InitialContext().lookup("javax.transaction.UserTransaction");

Session s1 = sf.openSession();
...
s1.flush();
s1.close();

...

Session s2 = sf.openSession();
...
s2.flush();
s2.close();

tx.commit();

s1不关闭，使用s2�q�行操作的代码中使用s1可不可以�Q�我觉得�q�样更加节约资源�Q�不需要反复的�q�接、关闭）

但sf.opengSession()�Ӟ��q�没有setAutoCommit(false)�Q�我想问的是�Q�如果不�~�写��M��事务代码�Q�如�Q?
Session s = sf.openSession();
......
s.close();
数据库会不会有反应（此时应该是默认AutoCommit为true�Q��?

不会有反应。在sf.openSession() 创徏Session实例的时候，��已�l�调用了conn.setAutoCommit(false)了�?

另外�Q�我想问一下：

1. s.flush()是不是必��ȝ��

2. s.close()是不是一定要关闭

--------------------------------------------------------------------------------

回答�Q?

s.flush不是必须的，s.close()会调用一�ơs.flush()

s.close()正常情况下应该关闭，除非你是用ThreadLocal��理Session�?

s1不关闭，使用s2�q�行操作的代码中使用s1可不可以�Q�我觉得�q�样更加节约资源�Q�不需要反复的�q�接、关闭）

在这个例子中看不出来JTA的作用�?
假设
Class A {
find() {
Session s1 = sf.openSession();
...
s1.flush();
s1.close();
}
}

Class B {
find() {
Session s2 = sf.openSession();
...
s2.flush();
s2.close();
}
}

Main {

tx = ...;
A.find();
B.find();
tx.commit();
} �Q�全文完�Q?

心晴 2008-10-24 16:07 发表评论

数据库事务与�q�发

心晴 — Thu, 17 Apr 2008 14:28:00 GMT

数据库事务必��d��备ACID特征,ACID是Atomic(原子�?,Consistency(一致�?,Isolation(隔离�?,和Durability(持久�?.

Atomic(原子�?:指整个数据库事务是不可分割的工作单元,只有事务中所有的操作执行成功,才算整个事务成功.
Consistency(一致�?:指数据库事务不能破换关系数据的完整性以及业务逻辑上的一致�?比如说银行�{帐事�?不管事务成功�q�是
��p�|,应该保证事务�l�束后的存款总额为原来的.)
Isolation(隔离�?:指在�q�发环境�?当不同的事务同时操纵相同的数据时,每个事务都有各自的完整数据空�?
Durability(持久�?:指的是只要事务成功工�l�束,它对数据库所做的更新��必��L��久保存下�?即��发生�pȝ��崩溃,从新启动数据库系�l�后,数据库还能恢复到事务成功�l�束时候的状�?

数据库管理系�l�采用日志来保证事务的原子�?一致性和持久�?日志记录了事务对数据库所做的更新,如果某个事务在执行过�E�中发生错误,��可以根据日�?撤消事务�Ҏ��据库已做的更�?使数据库退回到执行事务前的初始状�?

数据库管理系�l�采用锁机制来实��C��务的隔离�?当多个事务同时更新数据库中的相同的数据时,只允许只有锁的事务能更新该数�?其他事务必须�{�待,直到前一个事务释放了�?其他事务才有��Z��更新该数据�?/p>

(POJOs IN ACTION中文�?

隔离的（isolated�Q�数据库事务
有时�Q�你可以直接依赖数据库本�w�处理共享数据的�q�发讉K��。可以将数据库配�|�成执行�怺�隔离�Q�isolated�Q�用数据库的行话来讲�Q�的数据库事务。如果你�q�不熟悉�q�一概念�Q�请别担心，�W?2章里会进行详�l�说明。眼下最关键的是要记住，如果应用�E�序使用完全隔离的事务，那么同时执行两个事务的效果将与一个接一个执行这两个事务完全�{�效�?br /> 从表面上看，�q�种�Ҏ��看似非常��单，但这�c�M��务也存在问题�Q�由于隔��M��务如何实现完全由数据库决定，因此有时它们会导致性能降低�Q��o人无法接受。鉴于此�Q�许多应用程序都避免使用�q�类事务�Q��{而采用所谓的乐观�Q�optimistic�Q�或者悲观（pessimistic�Q�锁�Q�稍后将作描�q��?/p>

乐观�?br /> 处理�q�发更新的一�U�方式是使用乐观锁（optimistic locking�Q�。乐观锁的工作原理是让应用程序检查它卛_��更新的数据是否已被另一个事务修改（自该数据上次��d��以来�Q�。实��C��观锁的一�U�常见做法是在每个表里添加一个版本字�D�，每次应用�E�序更新数据表记录时��增加这个版本字�D�c��每个UPDATE语句中的WHERE子句会根据上�ơ读取的值来判断�q�个版本��h��否改变。通过查看PreparedStatement.executeUpdate()�q�回的记录数�Q�应用程序可以判断UPDATE语句是否成功。如果这条记录已被另一个事务更新或删除�Q�应用程序可以回滚这个事务，�q��新开始�?br /> 在直接执行SQL语句的应用程序中�Q�乐观锁机制的实现非常容易。不�q�，使用诸如JDO和Hibernate的持久层构架�Ӟ��实现更�ؓ�Ҏ��Q�因为它们已��乐观锁作�ؓ配置选项提供。一旦启用该配置选项�Q�持久层框架会自动生成SQL UPDATE语句�Q�执行版本检查。第12章将分析乐观锁的使用时机及其�~�点�Q��ƈ向你展示怎样在iBATIS、JDO和Hibernate中��用乐观锁�?br /> 乐观锁的名称源自如下假定情况�Q�即�q�发更新的几率极��，此外应用�E�序�q�不��L��q�发更新�Q�而是��ƈ发更斎ͼ��q�从�q�发更新中恢复过来。另一�U�方式是使用悲观锁（pessimistic locking�Q�，它假定�ƈ发更新将会发生，因此必须预先��L��?/p>

悲观�?/p>

不同于乐观锁的另一�U�方式是使用悲观锁。当��d��某些记录�Ӟ��事务先锁住这些记录，�q�样可以防止其他事务讉K��q�些数据记录。具体细节要视数据库而定�Q�不�q�糟�p�的是，�q��所有数据库都支持悲观锁。如果数据库支持悲观锁，在直接执行SQL语句的应用程序中�Q�实现悲观锁非常�Ҏ��。然而，正如你所预料的，在JDO或Hibernate应用�E�序中��用悲观锁更�ؓ�Ҏ��。JDO以配�|�选项的方式提供悲观锁�Q�而Hibernate则提供一个简单实用的API�Q�来锁定对象。同��P��在第12章，你将学习何时使用悲观锁，分析其缺点，�q�看看怎样在iBATIS、JDO和Hibernate中��用悲观锁�?/p>

除了处理单个数据库事务里的�ƈ发，通常你还必须处理跨一�p�d��数据库事务的�q�发

心晴 2008-04-17 22:28 发表评论