-->
These old forums are deprecated now and set to read-only. We are waiting for you on our new forums!
More modern, Discourse-based and with GitHub/Google/Twitter authentication built-in.

View unanswered posts | View active topics


Board index » Hibernate & Java Persistence » Hibernate Users

All times are UTC - 5 hours [ DST ]


Forum locked This topic is locked, you cannot edit posts or make further replies.  Page 1 of 1
  [ 12 posts ] 
  Previous topic | Next topic 
Author Message
Maria
 Post subject: Transaction management - rollback isn't performed
PostPosted: Mon Jun 20, 2005 10:39 am 
Newbie

Joined: Mon Jun 20, 2005 9:25 am
Posts: 7
Need help with Hibernate? Read this first:
http://www.hibernate.org/ForumMailingli ... AskForHelp

Hibernate version: 3.0
Borland Enterprise Server 5.2.1
Oracle DB 9. something

I get mysterious results when testing transaction management in a managed (CMT) environment.
I have prepared an objectstructure which will cause an error when inserted into the database.

hibernate.cfg.xml:
Code:
<hibernate-configuration>

    <session-factory>
<property name="connection.datasource">serial://datasources/driverDataSource_ELWEB_MERGE</property>    
        <property name="dialect">org.hibernate.dialect.Oracle9Dialect</property>
        <property name="show_sql">true</property>
         <property name="hibernate.transaction.manager_lookup_class">org.hibernate.transaction.BESTransactionManagerLookup </property> 
        <property name="hibernate.transaction.flush_before_completion">true</property>
        <property name="hibernate.transaction.auto_close_session">true</property>
        <property name="hibernate.connection.release_mode">auto</property>
         <property name="hibernate.transaction.factory_class">org.hibernate.transaction.CMTTransactionFactory</property>
        <property name="hibernate.cache.use_second_level_cache">true</property>
        <property name="hibernate.session_factory_name">serial://Hibernate/SessionFactory</property> 
      <property name="hibernate.use_sql_comments">true</property>
      
        <mapping resource="EnergyProfileVO.hbm.xml"/>
        <mapping resource="EnergyProfileRowVO.hbm.xml"/>

    </session-factory>




Code:
try
{
    Session session = sessionFactory.getCurrentSession();
    session.save(myObjectStructure);
}
catch (Throwable t)
{
    // I never get here
}


No exception is thrown and the database get updated with parts of the objectStructure so no rollback is performed.

What am I missing? According to the ref. manual you don't need to do any transaction demarkation when using CMT.

The error in the object structure is an attribute that is null mapped to an not-null column. When I declared the attribute as not-null i the object mapping an exception was thrown and rollback performed.
But shouldn't there be an exception and rollback either way???

This exception is thrown somewhere within Hibernate I think, I haven't been able to catch it anyway.
2005-jun-20 15:22:11 org.hibernate.util.JDBCExceptionReporter logExceptions
[Mon Jun 20 15:22:11 CEST 2005] VARNING: SQL Error: 1401, SQLState: 23000
[Mon Jun 20 15:22:11 CEST 2005] 2005-jun-20 15:22:11 org.hibernate.util.JDBCExceptionReporter logExceptions
[Mon Jun 20 15:22:11 CEST 2005] ALLVARLIG: ORA-01401: inserted value too large for column
[Mon Jun 20 15:22:11 CEST 2005]
[Mon Jun 20 15:22:11 CEST 2005] 2005-jun-20 15:22:11 org.hibernate.util.JDBCExceptionReporter logExceptions
[Mon Jun 20 15:22:11 CEST 2005] VARNING: SQL Error: 1401, SQLState: 23000
[Mon Jun 20 15:22:11 CEST 2005] 2005-jun-20 15:22:11 org.hibernate.util.JDBCExceptionReporter logExceptions
[Mon Jun 20 15:22:11 CEST 2005] ALLVARLIG: ORA-01401: inserted value too large for column
[Mon Jun 20 15:22:11 CEST 2005]
[Mon Jun 20 15:22:11 CEST 2005] 2005-jun-20 15:22:11 org.hibernate.event.def.AbstractFlushingEventListener performExecutions
[Mon Jun 20 15:22:11 CEST 2005] ALLVARLIG: Could not synchronize database state with session
[Mon Jun 20 15:22:11 CEST 2005] org.hibernate.exception.GenericJDBCException: Could not execute JDBC batch update
[Mon Jun 20 15:22:11 CEST 2005] at org.hibernate.exception.ErrorCodeConverter.handledNonSpecificException(ErrorCodeConverter.java:92)
[Mon Jun 20 15:22:11 CEST 2005] at org.hibernate.exception.ErrorCodeConverter.convert(ErrorCodeConverter.java:80)
[Mon Jun 20 15:22:11 CEST 2005] at org.hibernate.exception.JDBCExceptionHelper.convert(JDBCExceptionHelper.java:43)
[Mon Jun 20 15:22:11 CEST 2005] at org.hibernate.jdbc.AbstractBatcher.executeBatch(AbstractBatcher.java:181)
[Mon Jun 20 15:22:11 CEST 2005] at org.hibernate.engine.ActionQueue.executeActions(ActionQueue.java:226)
[Mon Jun 20 15:22:11 CEST 2005] at org.hibernate.engine.ActionQueue.executeActions(ActionQueue.java:136)
[Mon Jun 20 15:22:11 CEST 2005] at org.hibernate.event.def.AbstractFlushingEventListener.performExecutions(AbstractFlushingEventListener.java:274)
[Mon Jun 20 15:22:11 CEST 2005] at org.hibernate.event.def.DefaultFlushEventListener.onFlush(DefaultFlushEventListener.java:27)
[Mon Jun 20 15:22:11 CEST 2005] at org.hibernate.impl.SessionImpl.flush(SessionImpl.java:730)
[Mon Jun 20 15:22:11 CEST 2005] at org.hibernate.impl.SessionImpl.managedFlush(SessionImpl.java:324)
[Mon Jun 20 15:22:11 CEST 2005] at org.hibernate.transaction.CacheSynchronization.beforeCompletion(CacheSynchronization.java:58)
[Mon Jun 20 15:22:11 CEST 2005] at com.inprise.visitransact.jta.SynchronizationImpl.before_completion(SynchronizationImpl.java:63)
[Mon Jun 20 15:22:11 CEST 2005] at org.omg.CosTransactions._SynchronizationStub.before_completion(_SynchronizationStub.java:56)
[Mon Jun 20 15:22:11 CEST 2005] at com.inprise.ejb.jts.Transaction.commit(Transaction.java:425)
[Mon Jun 20 15:22:11 CEST 2005] at org.omg.CosTransactions._TerminatorStub.commit(_TerminatorStub.java:27)
[Mon Jun 20 15:22:11 CEST 2005] at com.inprise.ejb.jts.gen._TxStub.commit(_TxStub.java:46)
[Mon Jun 20 15:22:11 CEST 2005] at com.visigenic.services.CosTransactions.CurrentImpl.commit(CurrentImpl.java:260)
[Mon Jun 20 15:22:11 CEST 2005] at com.visigenic.services.CosTransactions.TSCurrentManager.commit(TSCurrentManager.java:87)
[Mon Jun 20 15:22:11 CEST 2005] at com.inprise.visitransact.jta.TransactionManagerImpl.commit(TransactionManagerImpl.java:198)
[Mon Jun 20 15:22:11 CEST 2005] at com.inprise.ejb.Dispatcher.endGlobalTransaction(Dispatcher.java:254)
[Mon Jun 20 15:22:11 CEST 2005] at com.inprise.ejb.Dispatcher.doInvoke(Dispatcher.java:1534)
[Mon Jun 20 15:22:11 CEST 2005] at com.inprise.ejb.Dispatcher.invokeSecurityCheck(Dispatcher.java:1023)
[Mon Jun 20 15:22:11 CEST 2005] at com.inprise.ejb.Dispatcher.invoke(Dispatcher.java:816)
[Mon Jun 20 15:22:11 CEST 2005] at com.inprise.ejb.Dispatcher.invoke(Dispatcher.java:595)
[Mon Jun 20 15:22:11 CEST 2005] at com.inprise.ejb.EJBHome.dispatcherInvokeBeanMethod(EJBHome.java:55)
[Mon Jun 20 15:22:11 CEST 2005] at com.inprise.ejb.EJBHome$ComponentInterfaceMethodCache.invokeDispatcherMethod(EJBHome.java:1502)
[Mon Jun 20 15:22:11 CEST 2005] at com.inprise.ejb.EJBHome.invokeDispatcherMethod(EJBHome.java:34)
[Mon Jun 20 15:22:11 CEST 2005] at com.inprise.ejb.Dispatcher.invoke(Dispatcher.java:416)
[Mon Jun 20 15:22:11 CEST 2005] at se.vattenfall.elwebb.surprice.profile.EnergyProfileServicesPOAInvokeHandler.createEnergyProfile(EnergyProfileServicesPOAInvokeHandler.java:58)
[Mon Jun 20 15:22:11 CEST 2005] at se.vattenfall.elwebb.surprice.profile.EnergyProfileServicesPOAInvokeHandler.createEnergyProfile(EnergyProfileServicesPOAInvokeHandler.java:206)
[Mon Jun 20 15:22:11 CEST 2005] at se.vattenfall.elwebb.surprice.profile.EnergyProfileServicesPOA._invoke(EnergyProfileServicesPOA.java:81)
[Mon Jun 20 15:22:11 CEST 2005] at se.vattenfall.elwebb.surprice.profile.EnergyProfileServicesPOA._invoke(EnergyProfileServicesPOA.java:61)
[Mon Jun 20 15:22:11 CEST 2005] at com.inprise.vbroker.poa.POAImpl.invoke(POAImpl.java:2693)
[Mon Jun 20 15:22:11 CEST 2005] at com.inprise.vbroker.poa.ActivationRecord.invoke(ActivationRecord.java:109)
[Mon Jun 20 15:22:11 CEST 2005] at com.inprise.vbroker.poa.ServerInterceptorManager$ARWrapper.invoke(ServerInterceptorManager.java:110)
[Mon Jun 20 15:22:11 CEST 2005] at com.inprise.vbroker.GIOP.GiopProtocolAdapter.doRequest(GiopProtocolAdapter.java:824)
[Mon Jun 20 15:22:11 CEST 2005] at com.inprise.vbroker.IIOP.ServerProtocolAdapter.doRequest(ServerProtocolAdapter.java:68)
[Mon Jun 20 15:22:11 CEST 2005] at com.inprise.vbroker.GIOP.GiopProtocolAdapter.dispatchMessage(GiopProtocolAdapter.java:1106)
[Mon Jun 20 15:22:11 CEST 2005] at com.inprise.vbroker.orb.TPDispatcherImpl$TPDispatcher.run(TPDispatcherImpl.java:106)
[Mon Jun 20 15:22:11 CEST 2005] at com.inprise.vbroker.orb.ThreadPool$PoolWorker.run(ThreadPool.java:76)
[Mon Jun 20 15:22:11 CEST 2005] Caused by: java.sql.BatchUpdateException: ORA-01401: inserted value too large for column
[Mon Jun 20 15:22:11 CEST 2005]
[Mon Jun 20 15:22:11 CEST 2005] at oracle.jdbc.dbaccess.DBError.throwBatchUpdateException(DBError.java:460)
[Mon Jun 20 15:22:11 CEST 2005] at oracle.jdbc.driver.OraclePreparedStatement.executeBatch(OraclePreparedStatement.java:4133)
[Mon Jun 20 15:22:11 CEST 2005] at org.hibernate.jdbc.BatchingBatcher.doExecuteBatch(BatchingBatcher.java:57)
[Mon Jun 20 15:22:11 CEST 2005] at org.hibernate.jdbc.AbstractBatcher.executeBatch(AbstractBatcher.java:174)
[Mon Jun 20 15:22:11 CEST 2005] ... 36 more
[Mon Jun 20 15:22:11 CEST 2005] org.hibernate.exception.GenericJDBCException: Could not execute JDBC batch update
[Mon Jun 20 15:22:11 CEST 2005] at org.hibernate.exception.ErrorCodeConverter.handledNonSpecificException(ErrorCodeConverter.java:92)
[Mon Jun 20 15:22:11 CEST 2005] at org.hibernate.exception.ErrorCodeConverter.convert(ErrorCodeConverter.java:80)
[Mon Jun 20 15:22:11 CEST 2005] at org.hibernate.exception.JDBCExceptionHelper.convert(JDBCExceptionHelper.java:43)
[Mon Jun 20 15:22:11 CEST 2005] at org.hibernate.jdbc.AbstractBatcher.executeBatch(AbstractBatcher.java:181)
[Mon Jun 20 15:22:11 CEST 2005] at org.hibernate.engine.ActionQueue.executeActions(ActionQueue.java:226)
[Mon Jun 20 15:22:11 CEST 2005] at org.hibernate.engine.ActionQueue.executeActions(ActionQueue.java:136)
[Mon Jun 20 15:22:11 CEST 2005] at org.hibernate.event.def.AbstractFlushingEventListener.performExecutions(AbstractFlushingEventListener.java:274)
[Mon Jun 20 15:22:11 CEST 2005] at org.hibernate.event.def.DefaultFlushEventListener.onFlush(DefaultFlushEventListener.java:27)
[Mon Jun 20 15:22:11 CEST 2005] at org.hibernate.impl.SessionImpl.flush(SessionImpl.java:730)
[Mon Jun 20 15:22:11 CEST 2005] at org.hibernate.impl.SessionImpl.managedFlush(SessionImpl.java:324)
[Mon Jun 20 15:22:11 CEST 2005] at org.hibernate.transaction.CacheSynchronization.beforeCompletion(CacheSynchronization.java:58)
[Mon Jun 20 15:22:11 CEST 2005] at com.inprise.visitransact.jta.SynchronizationImpl.before_completion(SynchronizationImpl.java:63)
[Mon Jun 20 15:22:11 CEST 2005] at org.omg.CosTransactions._SynchronizationStub.before_completion(_SynchronizationStub.java:56)
[Mon Jun 20 15:22:11 CEST 2005] at com.inprise.ejb.jts.Transaction.commit(Transaction.java:425)
[Mon Jun 20 15:22:11 CEST 2005] at org.omg.CosTransactions._TerminatorStub.commit(_TerminatorStub.java:27)
[Mon Jun 20 15:22:11 CEST 2005] at com.inprise.ejb.jts.gen._TxStub.commit(_TxStub.java:46)
[Mon Jun 20 15:22:11 CEST 2005] at com.visigenic.services.CosTransactions.CurrentImpl.commit(CurrentImpl.java:260)
[Mon Jun 20 15:22:11 CEST 2005] at com.visigenic.services.CosTransactions.TSCurrentManager.commit(TSCurrentManager.java:87)
[Mon Jun 20 15:22:11 CEST 2005] at com.inprise.visitransact.jta.TransactionManagerImpl.commit(TransactionManagerImpl.java:198)
[Mon Jun 20 15:22:11 CEST 2005] at com.inprise.ejb.Dispatcher.endGlobalTransaction(Dispatcher.java:254)
[Mon Jun 20 15:22:11 CEST 2005] at com.inprise.ejb.Dispatcher.doInvoke(Dispatcher.java:1534)
[Mon Jun 20 15:22:11 CEST 2005] at com.inprise.ejb.Dispatcher.invokeSecurityCheck(Dispatcher.java:1023)
[Mon Jun 20 15:22:11 CEST 2005] at com.inprise.ejb.Dispatcher.invoke(Dispatcher.java:816)
[Mon Jun 20 15:22:11 CEST 2005] at com.inprise.ejb.Dispatcher.invoke(Dispatcher.java:595)
[Mon Jun 20 15:22:11 CEST 2005] at com.inprise.ejb.EJBHome.dispatcherInvokeBeanMethod(EJBHome.java:55)
[Mon Jun 20 15:22:11 CEST 2005] at com.inprise.ejb.EJBHome$ComponentInterfaceMethodCache.invokeDispatcherMethod(EJBHome.java:1502)
[Mon Jun 20 15:22:11 CEST 2005] at com.inprise.ejb.EJBHome.invokeDispatcherMethod(EJBHome.java:34)
[Mon Jun 20 15:22:11 CEST 2005] at com.inprise.ejb.Dispatcher.invoke(Dispatcher.java:416)
[Mon Jun 20 15:22:11 CEST 2005] at se.vattenfall.elwebb.surprice.profile.EnergyProfileServicesPOAInvokeHandler.createEnergyProfile(EnergyProfileServicesPOAInvokeHandler.java:58)
[Mon Jun 20 15:22:11 CEST 2005] at se.vattenfall.elwebb.surprice.profile.EnergyProfileServicesPOAInvokeHandler.createEnergyProfile(EnergyProfileServicesPOAInvokeHandler.java:206)
[Mon Jun 20 15:22:11 CEST 2005] at se.vattenfall.elwebb.surprice.profile.EnergyProfileServicesPOA._invoke(EnergyProfileServicesPOA.java:81)
[Mon Jun 20 15:22:11 CEST 2005] at se.vattenfall.elwebb.surprice.profile.EnergyProfileServicesPOA._invoke(EnergyProfileServicesPOA.java:61)
[Mon Jun 20 15:22:11 CEST 2005] at com.inprise.vbroker.poa.POAImpl.invoke(POAImpl.java:2693)
[Mon Jun 20 15:22:11 CEST 2005] at com.inprise.vbroker.poa.ActivationRecord.invoke(ActivationRecord.java:109)
[Mon Jun 20 15:22:11 CEST 2005] at com.inprise.vbroker.poa.ServerInterceptorManager$ARWrapper.invoke(ServerInterceptorManager.java:110)
[Mon Jun 20 15:22:11 CEST 2005] at com.inprise.vbroker.GIOP.GiopProtocolAdapter.doRequest(GiopProtocolAdapter.java:824)
[Mon Jun 20 15:22:11 CEST 2005] at com.inprise.vbroker.IIOP.ServerProtocolAdapter.doRequest(ServerProtocolAdapter.java:68)
[Mon Jun 20 15:22:11 CEST 2005] at com.inprise.vbroker.GIOP.GiopProtocolAdapter.dispatchMessage(GiopProtocolAdapter.java:1106)
[Mon Jun 20 15:22:11 CEST 2005] at com.inprise.vbroker.orb.TPDispatcherImpl$TPDispatcher.run(TPDispatcherImpl.java:106)
[Mon Jun 20 15:22:11 CEST 2005] at com.inprise.vbroker.orb.ThreadPool$PoolWorker.run(ThreadPool.java:76)
[Mon Jun 20 15:22:11 CEST 2005] Caused by: java.sql.BatchUpdateException: ORA-01401: inserted value too large for column
[Mon Jun 20 15:22:11 CEST 2005]
[Mon Jun 20 15:22:11 CEST 2005] at oracle.jdbc.dbaccess.DBError.throwBatchUpdateException(DBError.java:460)
[Mon Jun 20 15:22:11 CEST 2005] at oracle.jdbc.driver.OraclePreparedStatement.executeBatch(OraclePreparedStatement.java:4133)
[Mon Jun 20 15:22:11 CEST 2005] at org.hibernate.jdbc.BatchingBatcher.doExecuteBatch(BatchingBatcher.java:57)
[Mon Jun 20 15:22:11 CEST 2005] at org.hibernate.jdbc.AbstractBatcher.executeBatch(AbstractBatcher.java:174)
[Mon Jun 20 15:22:11 CEST 2005] ... 36 more
Top
 Profile  
 
max
 Post subject:
PostPosted: Fri Aug 12, 2005 12:23 pm 
Hibernate Team
Hibernate Team

Joined: Tue Aug 26, 2003 6:10 am
Posts: 8615
Location: Neuchatel, Switzerland (Danish)
if the database inserts the data without problems why should there be an exception ?

_________________
Max
Don't forget to rate

Top
 Profile  
 
Maria
 Post subject:
PostPosted: Mon Aug 15, 2005 3:23 am 
Newbie

Joined: Mon Jun 20, 2005 9:25 am
Posts: 7
Let's say we have an object structure that looks like this:

Customer
Address 1 (OK)
Address 2 (street name has more characters than the DB-table allows)
Address 3 (OK)

The Customer and Address 1 gets inserted into the database, but not Address 2 and 3. No Hibernate exception is thrown.

I would like to have a rollback and a HibernateException.
Top
 Profile  
 
gavin
 Post subject:
PostPosted: Mon Aug 15, 2005 3:30 am 
Hibernate Team
Hibernate Team

Joined: Tue Aug 26, 2003 12:50 pm
Posts: 5130
Location: Melbourne, Australia
This has nothing to do with Hibernate. Every database on earth except for one (MySQL, I think) throws an exception in this case.

If you want to have Hibernate do Java-level validation automatically, try Hibernate Validator (part of the Annotations sub-project).
Top
 Profile  
 
Maria
 Post subject:
PostPosted: Mon Aug 15, 2005 4:42 am 
Newbie

Joined: Mon Jun 20, 2005 9:25 am
Posts: 7
Hmm, I'm not sure we understand each other.

Let me try to explain how I see it one more time:

In the SessionBean:
Code:
try {
    session.save(myObject);
}
catch (Throwable t) {
    // I never get here
}


In the servlet:

Code:
try {
    sessionbean.saveObject(myObject);
}
catch (Throwable t) {
    // I never get here
}


setRollbackOnly() is never set on the sessionbean. I don't get any indication that the update didn't go well so I can't set i manually either.

I thougth that Hibernate should call setRollbackOnly on the sessionbean.

Do you mean that the SessionBean should discover that the DB-update didn't go well and perform a rollback without any hint from Hibernate?
Top
 Profile  
 
max
 Post subject:
PostPosted: Mon Aug 15, 2005 4:49 am 
Hibernate Team
Hibernate Team

Joined: Tue Aug 26, 2003 6:10 am
Posts: 8615
Location: Neuchatel, Switzerland (Danish)
the actual sql is not always performed when you call session.save() it is done at flush time. Flush occurs when you do session.flush() or tx.commit().

That is why you dont get the exception when calling .save

_________________
Max
Don't forget to rate

Top
 Profile  
 
gavin
 Post subject:
PostPosted: Mon Aug 15, 2005 4:50 am 
Hibernate Team
Hibernate Team

Joined: Tue Aug 26, 2003 12:50 pm
Posts: 5130
Location: Melbourne, Australia
Why do you think Hibernate should call setRollbackOnly().

A runtime exception propagating out of beforeCompletion() will automatically roll back the transaction, as per the EJB and JTA specs.

By the way, you seem to be a bit confused about when Hibernate executes SQL inserts and updates. It all happens at *flush* time; not when you call saveOrUpdate(). Please refer to the docs.
Top
 Profile  
 
gavin
 Post subject:
PostPosted: Mon Aug 15, 2005 4:51 am 
Hibernate Team
Hibernate Team

Joined: Tue Aug 26, 2003 12:50 pm
Posts: 5130
Location: Melbourne, Australia
Quote:
No exception is thrown and the database get updated with parts of the objectStructure so no rollback is performed.


If this is really true, it is a bug in your appserver. I find it very difficult to believe, however.
Top
 Profile  
 
gavin
 Post subject:
PostPosted: Mon Aug 15, 2005 5:10 am 
Hibernate Team
Hibernate Team

Joined: Tue Aug 26, 2003 12:50 pm
Posts: 5130
Location: Melbourne, Australia
gavin wrote:
Quote:
No exception is thrown and the database get updated with parts of the objectStructure so no rollback is performed.


If this is really true, it is a bug in your appserver. I find it very difficult to believe, however.



Hum, well, actually.

I just checked the JTA and EJB specs and they seem to be silent on this issue. My understanding is that almost all appservers will behave in the way I describe. For example, JBoss does this:

Code:
   private void doBeforeCompletion()
   {
      unlock();
      try
      {
         for (int i = 0; i < syncCount; i++)
         {
            try
            {
               if (trace)
                  log.trace("calling sync " + i + ", " + sync[i] +
                            " tx=" + this);

               sync[i].beforeCompletion();
            }
            catch (Throwable t)
            {
               if (trace)
                  log.trace("failed before completion " + sync[i], t);

               status = Status.STATUS_MARKED_ROLLBACK;

               // save the cause off so the user can inspect it
               cause = t;
               break;
            }
         }
      }
      finally
      {
         lock();
      }
   }


WebSphere behaves the same, according to their docs.

But, I suppose if Borland is doing something different (and a bit crazy), and this is not completely nailed down by the spec, then we should call setRollbackOnly() explictly.
Top
 Profile  
 
gavin
 Post subject:
PostPosted: Mon Aug 15, 2005 5:15 am 
Hibernate Team
Hibernate Team

Joined: Tue Aug 26, 2003 12:50 pm
Posts: 5130
Location: Melbourne, Australia
Hah. Actually the EJB spec *is* explicit about the behavior of SessionSynchronization.beforeTransactionCompletion(). (It is the expected behavior.) Unfortunately the JTA spec is silent on Synchronization.beforeTransactionCompletion().
Top
 Profile  
 
gavin
 Post subject:
PostPosted: Mon Aug 15, 2005 5:25 am 
Hibernate Team
Hibernate Team

Joined: Tue Aug 26, 2003 12:50 pm
Posts: 5130
Location: Melbourne, Australia
OK, so in CVS I added a call to setRollbackOnly().

This helps you somewhat, I guess.

But if Borland is swallowing the exception, you still won't see any failure, just the txn rollback. Not a great deal I can do about that, I'm afraid. Complain to Borland.
Top
 Profile  
 
Maria
 Post subject:
PostPosted: Mon Aug 15, 2005 7:33 am 
Newbie

Joined: Mon Jun 20, 2005 9:25 am
Posts: 7
Thank you very much for your help!!!
Top
 Profile  
 
Display posts from previous:  Sort by  
Forum locked This topic is locked, you cannot edit posts or make further replies.  Page 1 of 1
  [ 12 posts ] 

Board index » Hibernate & Java Persistence » Hibernate Users

All times are UTC - 5 hours [ DST ]

You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum

Search for:
© Copyright 2014, Red Hat Inc. All rights reserved. JBoss and Hibernate are registered trademarks and servicemarks of Red Hat, Inc.