我正在使用无状态EJB类来更新位于数据库中的持久性实体。 EJB中的方法调用完成工作的实现类。我认为导致问题的原因是名为Foo
的实体与实体Bar
具有oneToMany关系。事情已经完成,会话将使用Foo
进行更新,其中“{1}}级联'到Bar
。发生StaleObjectStateException
时,事务未完全回滚,这会导致错误,原因很明显。
EJB :
private Session getSession() throws BusinessException {
if( this.sess == null ) {
ServiceLocator locator = new ServiceLocator();
SessionFactory sf = locator.getHibernateSessionFactory();
this.sess = sf.openSession();
}
return this.sess;
}
private ProductionOrderImpl getImpl() throws BusinessException {
if( this.impl == null ) {
this.impl = new ProductionOrderImpl( getSession() );
}
return this.impl;
}
public void cutoffOrders( ) throws Exception {
Transaction tx = null;
try {
tx = getSession().beginTransaction();
getImpl().cutOffFoos(fooTime);
tx.commit();
} catch (StaleObjectStateException e1){
if (tx != null) tx.rollback();
logger.error( "Failed to cutoff order : " + e1 );
throw new Exception( LocaleMgr.getMessage());
}
finally {
// reset implementation object, close session,
// and reset session object
impl = null;
sess.close();
sess = null;
}
}
实施:
public ProductionOrderImpl(Session sess) {
this.sess = sess;
}
public void cutoffFoos( Timestamp fooTime) throws Exception {
... Code that gets fooList ...
if( fooList != null ) {
for( Foo foo: fooList ) {
for( Bar bar : foo.getBarList() ) {
... Code that does things with existing Barlist ...
if( ... ) {
... Code that makes new Bar object ...
foo.getBarList().add(bar2);
}
}
sess.update( foo );
}
}
}
相关的Foo代码:
@OneToMany(cascade=CascadeType.ALL, mappedBy="foo")
@OrderBy("startTime DESC")
Set<Bar> barList;
基本上,当Transaction尝试回滚时,已更改的Bar部分将被回滚,但新的Bar(代码中的bar2)记录仍然存在。
任何指导都将不胜感激。就像我说的,我相信这里的错误与sess.update(foo)
有关;可能与autocommit
有关,但默认情况下应关闭。
我相信发生的事情是,Session.Update(foo)反过来又创建了两个独立的事务。具体来说,更新Foo
(SQL UPDATE),但保存Bar
(SQL INSERT)。由于事务上下文只会真正看到SQL UPDATE,所以它就会反转。将不得不考虑更多..
我尝试将Session.FlushMode
更改为COMMIT
,但它似乎仍无法解决问题。但它确实可以部分修复问题。除了导致StaleObjectStateException的特定条目外,它将正确回滚条目。该特定条目实际上已从数据库中删除...
答案 0 :(得分:4)
我设法解决了我的问题..我会等着接受它以防其他人发布更好的东西,更多的东西...... 赏金。
基本上,通过将FlushMode
更改为手动,并在整个过程中手动刷新,我可以更早地捕获StaleObjectException
,这可以更快地支持代码。我仍然有部分回滚记录的工件。但是,这种方法按计划每2分钟运行一次,因此在第二次传递期间它会修复所有问题。
我将EJB更改为具有以下内容:
public void cutoffOrders( ) throws Exception {
Transaction tx = null;
try {
tx = getSession().beginTransaction();
getSession().setFlushMode(FlushMode.MANUAL);
getImpl().cutOffFoos(fooTime);
getSession().flush();
tx.commit();
} catch (StaleObjectStateException e1){
if (tx != null) tx.rollback();
logger.error( "Failed to cutoff order : " + e1 );
throw new Exception( LocaleMgr.getMessage());
}
finally {
// reset implementation object, close session,
// and reset session object
impl = null;
sess.close();
sess = null;
}
}
然后实现代码具有以下内容:
public void cutoffFoos( Timestamp fooTime) throws Exception {
... Code that gets fooList ...
if( fooList != null ) {
for( Foo foo: fooList ) {
for( Bar bar : foo.getBarList() ) {
... Code that does things with existing Barlist ...
sess.flush();
if( ... ) {
... Code that makes new Bar object ...
foo.getBarList().add(bar2);
}
}
sess.flush();
sess.update( foo );
}
}
}
答案 1 :(得分:1)
嗯,这是我的两分钱,因为这也与JPA有关:
在Spring Data JPA中,您可以使用以下内容:
1.在进行存储库调用之前进行@Transactional注释(处理回滚)
2.使用JPA存储库saveAndFlush方法,即:
@Service
public class ProductionOrderServiceImpl extends ProductionOrderService{
@Autowired
ProductionOrderRepository jpaRepository;
@Transactional
public void cutoffOrders( Timestamp fooTime ){
... Code that gets fooList ...
if( fooList != null ) {
for( Foo foo: fooList ) {
for( Bar bar : foo.getBarList() ) {
... Code that does things with existing Barlist ...
{Call another similar method with @transactional..}//saveAndFlush(BarList);
if( ... ) {
... Code that makes new Bar object ...
foo.getBarList().add(bar2);
}
}
jpaRepository.saveAndFlush(foo);
}
}
}
}
内部的保存和刷新是这样的:
/*
* (non-Javadoc)
* @see org.springframework.data.repository.CrudRepository#save(java.lang.Object)
*/
@Transactional
public <S extends T> S save(S entity) {
if (entityInformation.isNew(entity)) {
em.persist(entity);
return entity;
} else {
return em.merge(entity);
}
}
然后是em.flush();
如果遇到这种情况,如果你遇到@Audited版本问题,那里删除的记录没有显示,那么设置org.hibernate.envers.store_data_at_delete = true。
希望为解决方案增加视角。