transaction timeout not working on hibernate with oracle - oracle

I am having problem setting the transaction timeout for hibernate on oracle. It does not work.Can anyone help?
The "SaveOrUpdate" will not return within the stated 10 seconds. It will hang for a very long time.
I am using Oracle 10r2.
Hibernate Configuration File
<hibernate-configuration>
<session-factory>
<property name="connection.driver_class">oracle.jdbc.driver.OracleDriver</property>
<property name="connection.url">jdbc:oracle:thin:#9.9.9.9:1521:orcl</property>
<property name="connection.username">foouser</property>
<property name="connection.password">foopass</property>
<property name="hibernate.c3p0.min_size">5</property>
<property name="hibernate.c3p0.max_size">20</property>
<property name="dialect">org.hibernate.dialect.Oracle9Dialect</property>
<property name="current_session_context_class">thread</property>
<!-- Disable the second-level cache -->
<property name="cache.provider_class">org.hibernate.cache.NoCacheProvider</property>
<!-- Echo all executed SQL to stdout -->
<property name="show_sql">false</property>
<!-- Mapping files -->
<mapping resource="foo.hbm.xml"/>
</session-factory>
</hibernate-configuration>
Hibernate class
public class foo implements Serializable
{
...
public void save() throws Exception
{
Session dbSession = null;
Transaction tran = null;
try
{
dbSession = PersistenceMgr.getPersistenceMgr().getDbSession();
tran = dbSession.beginTransaction();
tran.setTimeout(10); // 10 seconds
dbSession.saveOrUpdate(this);
tran.commit();
}
catch (HibernateException e)
{
if(tran!=null)
{
try{tran.rollback();}
catch(HibernateException he){}
}
...
}
finally
{
if( dbSession != null )
{
try{dbSession.close();}
catch(HibernateException e){}
}
}
}
}

The timeout needs to be set before the transaction is started.
instead of
tran = dbSession.beginTransaction();
tran.setTimeout(10);// 10 seconds
try
tran = dbSession.getTransaction();
tran.setTimeout(10);
tran.begin();

You can see that at: http://community.jboss.org/wiki/TransactionTimeout.

Is this using JTA? If not, JDBC itself has no API for setting a transaction timeout so instead Hibernate attempts to manage that by tracking how much of the specified timeout period remains when executing a JDBC Statement within the transaction and setting the Statement.setQueryTimeout. It could be that there is either a bug in that logic or that the Oracle JDBC driver has a bug with regard to setting statement timeout.
If you find it is a Hibernate bug, https://hibernate.onjira.com

Related

Hibernate Transaction Manager not committing data changes

I'm using Hibernate 4 to write data to an H2 embedded in-memory database and there seems to be a problem with transactions. The application already uses Oracle and H2 has been added with a separate DataSource, SessionFactory, and TransactionManager. The original TransactionManager is marked as default and the H2 TransactionManager has the qualifier memTransactions
The following code - specifically the load function - correctly populates the memEvents variable at the end with the written data.
#Repository
#Transactional(transactionManager = "memTransactions")
public class EventMemDaoHibernate implements EventMemDao {
#Autowired
#Qualifier(value = "memSessionFactory")
private SessionFactory memSessionFactory;
#Override
public List<EventMem> getEvents() {
return memSessionFactory.getCurrentSession().createCriteria(EventMem.class).list();
}
#Override
public void load(List<Event> allEvents) {
Session session = memSessionFactory.getCurrentSession();
for (Event e : allEvents) {
EventMem memEvent = new EventMem(e);
session.save(memEvent);
}
List<EventMem> memEvents = getEvents(); // correct
}
}
However the following code produces an empty memEvents list
#Autowired
private EventMemDao eventMemDao;
List<Event> allEvents = eventDao.getAllEvents();
eventMemDao.load(allEvents); // calls the load function shown above
List<EventMem> memEvents = eventMemDao.getEvents(); // empty
I assume this is related to transaction management (e.g.: data is not auto-committed after the call to .save()). However when I tried explicitly beginning and committing a transaction within EventMemDaoHibernate#load, I receive this error:
nested transactions not supported
So, from what I can tell the TransactionManager is working.
My TransactionManager and related bean definitions are shown below.
<bean
id="memTransactionManager"
class="org.springframework.orm.hibernate4.HibernateTransactionManager">
<property name="sessionFactory" ref="memSessionFactory" />
<qualifier value="memTransactions"/>
</bean>
<bean id="hDataSource" class="org.h2.jdbcx.JdbcDataSource">
<property name="url" value="jdbc:h2:mem:db1;DB_CLOSE_DELAY=-1;INIT=RUNSCRIPT FROM 'classpath:scripts/init-h2.sql'" />
<property name="user" value="sa" />
<property name="password" value="" />
</bean>
<bean
id="memSessionFactory"
class="org.springframework.orm.hibernate4.LocalSessionFactoryBean">
<property name="dataSource" ref="hDataSource" />
<property name="hibernateProperties">
<props>
<prop key="hibernate.dialect">org.hibernate.dialect.H2Dialect</prop>
</props>
</property>
</bean>
This was due to my configuration error (of course). I didn't fully grasp that the connection URL was evaluated every time a session was opened against H2 and that means init-h2.sql was executed repeatedly. init-h2.sql included a truncate followed by an insert so it was dropping and recreating data every time Hibernate opened a session.

Hibernate saveorupdateall not doing save not update

I have a spring integration hibernate application. My application picks up files and checks their entries against the database. For this i am using Hibernate.
I want to disable certain rows in the database. I am retrieving the rows using criteria. Editing one field and using saveorupdateall method. This is not changing my db rows at all!!
Following are the code snippets
<bean id="dmsdbDetectionJob" class="com.polling.scheduler.job.DMSDBDetectionJob">
</bean>
<bean id="dmsdbDetectionJobDetail" class="org.springframework.scheduling.quartz.MethodInvokingJobDetailFactoryBean">
<property name="targetObject" ref="dmsdbDetectionJob" />
<property name="targetMethod" value="deleteDBMaster" />
<property name="concurrent" value="false" />
</bean>
<bean id="simpleTriggerDB" class="org.springframework.scheduling.quartz.CronTriggerBean">
<property name="jobDetail" ref="dmsdbDetectionJobDetail" />
<!-- <property name="cronExpression" value="1 * * * * ?" /> -->
<!-- <property name="cronExpression" value="0 0/1 * * * ?" /> -->
<property name="cronExpression" value="0 52 11 ? * *" />
</bean>
This fires at given time properly. deleteDBMaster method calls this code:
//get Document files not having any links
List<DocumentFile> strayFiles = documentDaoImpl.getStrayDocumentFiles();
try
{
if (strayFiles.size() > 0)
{
//delete
strayFiles = documentDaoImpl.softDelete(strayFiles, DocumentFile.class);
documentDaoImpl.saveOrUpdateAll(strayFiles);}
}...
The softDelete method uses generics
#Override
public <T extends GenericEntity> List<T> softDelete(List<T> stray,
Class<T> clazz)
{
for (T tObj : stray)
{
clazz.cast(tObj).setActive(Constants.INACTIVE.getVal());
}
return stray;
}
When I debug I see the value changed in the active property of the objects in the strayFiles list, inside saveOrUpdateAll() method. The saveOrUpdateAll method is:
#Override
public void saveOrUpdateAll(Collection<?> objects) throws DMSException {
try {
for (Object object : objects) {
getCrntSession().saveOrUpdate(object);
}
} catch (final HibernateException e) {
throw new DMSException("Exception while save or update All ", ErrorCode.BASE_DB_ERROR, e);
}
}
When the saveorupdate is called no query is logged by hibernate. Nothing changes in the db!!
Since this is in spring integration I have just added a #Transactional to the method. I am presuming that spring must do the flush or commit. Is that wrong? And even then I should see the query right??
Please let me know what is wrong in the code...
Thanks
EDIT::
Change my softdelete code to the following. Thought maybe the generics are causing this.
#Override
#Transactional
public void softDeleteDocumentFile(
List<DocumentFile> stray)
{
for (DocumentFile tObj : stray)
{
tObj.setActive(Constants.INACTIVE.getVal());
saveEntity(tObj);
}
}
Still no change. The rows are not getting updated. Hibernate is not printing the update query on the console!!
Please let me know if anyone finds any mistake in the code..
EDIT::
This is the configuration
<mvc:annotation-driven />
<context:component-scan base-package="com.polling" />
<bean
class="org.springframework.web.servlet.view.InternalResourceViewResolver">
<property name="prefix">
<value>/WEB-INF/</value>
</property>
<property name="suffix">
<value>.jsp</value>
</property>
</bean>
<context:property-placeholder location="classpath:config/jdbc.properties,classpath:config/config.properties,classpath:config/ftp.properties"/>
<bean id="dataSource"
class="org.springframework.jdbc.datasource.DriverManagerDataSource"
>
<property name="driverClassName" value="${jdbc.driverClassName}"/>
<property name="url" value="${jdbc.url}"/>
<property name="username" value="${jdbc.username}"/>
<property name="password" value="${jdbc.password}"/>
</bean>
<!-- Configure Hibernate 4 Session Factory -->
<bean id="sessionFactory"
class="org.springframework.orm.hibernate4.LocalSessionFactoryBean">
<property name="dataSource">
<ref bean="dataSource" />
</property>
<property name="hibernateProperties">
<props>
<prop key="hibernate.dialect">${hibernate.dialect}</prop>
<prop key="hibernate.show_sql">${hibernate.show_sql}</prop>
<prop key="hibernate.format_sql">${hibernate.format_sql}</prop>
<prop key="hibernate.generate_statistics">${hibernate.generate_statistics}</prop>
</props>
</property>
<property name="packagesToScan">
<list>
<value>com.polling.entity</value>
</list>
</property>
</bean>
<tx:annotation-driven />
<bean id="transactionManager"
class="org.springframework.orm.hibernate4.HibernateTransactionManager">
<property name="sessionFactory" ref="sessionFactory" />
</bean>
EDIT::
Tried using a hardcoded id. Used update instead of save. But still same result, no update query and hence no change in row!!
EDIT::
This is the log at trace level
14:31:12.644 T|TransactionInterceptor |Completing transaction for [com.polling.service.DocumentServiceImpl.deActivateStrays]
14:31:12.644 T|TransactionInterceptor |Completing transaction for [com.polling.scheduler.job.DMSDBDetectionJob.deleteDBMaster]
14:31:12.675 T|HibernateTransactionManager |Triggering beforeCommit synchronization
14:31:12.675 T|HibernateTransactionManager |Triggering beforeCompletion synchronization
14:31:12.675 D|HibernateTransactionManager |Initiating transaction commit
14:31:12.675 D|HibernateTransactionManager |Committing Hibernate transaction on Session [SessionImpl(PersistenceContext[entityKeys=[EntityKey[com.polling.entity.DocumentFile#273], EntityKey[com.polling.entity.DocumentGroup#107], EntityKey[com.polling.entity.DocumentFile#275]],collectionKeys=[CollectionKey[com.polling.entity.DocumentFile.docgroups#275], CollectionKey[com.polling.entity.DocumentGroup.files#107], CollectionKey[com.polling.entity.DocumentFile.docgroups#273]]];ActionQueue[insertions=org.hibernate.engine.spi.ExecutableList#2a6f7180 updates=org.hibernate.engine.spi.ExecutableList#7a84a043 deletions=org.hibernate.engine.spi.ExecutableList#1935cd8c orphanRemovals=org.hibernate.engine.spi.ExecutableList#1b49af42 collectionCreations=org.hibernate.engine.spi.ExecutableList#291240d collectionRemovals=org.hibernate.engine.spi.ExecutableList#6d5d2cc collectionUpdates=org.hibernate.engine.spi.ExecutableList#40025295 collectionQueuedOps=org.hibernate.engine.spi.ExecutableList#587bd507 unresolvedInsertDependencies=UnresolvedEntityInsertActions[]])]
14:31:12.675 D|AbstractTransactionImpl |committing
14:31:12.675 T|SessionImpl |Automatically flushing session
14:31:12.675 T|AbstractFlushingEventListener |Flushing session
14:31:12.675 D|AbstractFlushingEventListener |Processing flush-time cascades
14:31:12.675 T|Cascade |Processing cascade ACTION_SAVE_UPDATE for: com.polling.entity.DocumentFile
14:31:12.675 T|Cascade |Done processing cascade ACTION_SAVE_UPDATE for: com.polling.entity.DocumentFile
14:31:12.675 T|Cascade |Processing cascade ACTION_SAVE_UPDATE for: com.polling.entity.DocumentFile
14:31:12.675 T|Cascade |Done processing cascade ACTION_SAVE_UPDATE for: com.polling.entity.DocumentFile
14:31:12.675 D|AbstractFlushingEventListener |Dirty checking collections
14:31:12.675 T|AbstractFlushingEventListener |Flushing entities and processing referenced collections
14:31:12.675 D|Collections |Collection found: [com.polling.entity.DocumentFile.docgroups#273], was: [com.polling.entity.DocumentFile.docgroups#273] (uninitialized)
14:31:12.691 D|Collections |Collection found: [com.polling.entity.DocumentFile.docgroups#275], was: [com.polling.entity.DocumentFile.docgroups#275] (uninitialized)
14:31:12.691 D|Collections |Collection found: [com.polling.entity.DocumentGroup.files#107], was: [com.polling.entity.DocumentGroup.files#107] (uninitialized)
14:31:12.691 T|AbstractFlushingEventListener |Processing unreferenced collections
14:31:12.691 T|AbstractFlushingEventListener |Scheduling collection removes/(re)creates/updates
14:31:12.691 D|AbstractFlushingEventListener |Flushed: 0 insertions, 0 updates, 0 deletions to 3 objects
14:31:12.691 D|AbstractFlushingEventListener |Flushed: 0 (re)creations, 0 updates, 0 removals to 3 collections
14:31:12.691 D|EntityPrinter |Listing entities:
14:31:12.691 D|EntityPrinter |com.polling.entity.DocumentFile{encodingKey=yyy, docgroups=<uninitialized>, contactNumber=12121212, documentType=com.polling.entity.DocumentType#5, totalLinks=1, modifiedBy=com.polling.entity.UserApplicationGroup#3, documentFileName=f11, documentDescription=null, totalDownloads=0, uploaderCompletePath=somepath/somepath, modifiedDate=2014-12-16 14:36:57.707, size=0, DMSPath=c:/DMSFinalRoot\dir0\File0, id=273, createdBy=com.polling.entity.UserApplicationGroup#3, documentFormat=com.polling.entity.DocumentFormat#1, uploadDateTime=2014-12-16 14:36:56.86, keyWords=null, active=3, uploadStage=1, uploaderIP=0:0:0:0:0:0:0:1, createdDate=2014-12-16 14:36:57.707, contactPerson=some name, uploaderName=scmsname}
14:31:12.691 D|EntityPrinter |com.polling.entity.DocumentGroup{files=<uninitialized>, expiryPresent=false, modifiedBy=com.polling.entity.UserApplicationGroup#3, uploadStatus=0, documentDescription=null, modifiedDate=2014-12-22 14:28:09.027, id=107, nodeId=206, totalFiles=0, createdBy=com.polling.entity.UserApplicationGroup#3, documentFormat=null, objectId=101, active=3, documentName=doc1, nodeType=document, objectType=demand, createdDate=2014-12-22 14:28:09.027, expiryAt=null}
14:31:12.691 D|EntityPrinter |com.polling.entity.DocumentFile{encodingKey=azaz, docgroups=<uninitialized>, contactNumber=12121212, documentType=com.polling.entity.DocumentType#5, totalLinks=1, modifiedBy=com.polling.entity.UserApplicationGroup#3, documentFileName=f11, documentDescription=null, totalDownloads=0, uploaderCompletePath=somepath/somepath, modifiedDate=2014-12-17 16:52:23.163, size=0, DMSPath=c:/DMSFinalRoot\dir2\File0, id=275, createdBy=com.polling.entity.UserApplicationGroup#3, documentFormat=com.polling.entity.DocumentFormat#1, uploadDateTime=2014-12-17 16:52:22.127, keyWords=null, active=9, uploadStage=1, uploaderIP=0:0:0:0:0:0:0:1, createdDate=2014-12-17 16:52:23.163, contactPerson=some name, uploaderName=scmsname}
14:31:12.691 T|AbstractFlushingEventListener |Executing flush
14:31:12.691 T|JdbcCoordinatorImpl |Starting after statement execution processing [ON_CLOSE]
14:31:12.691 T|AbstractFlushingEventListener |Post flush
14:31:12.691 T|SessionImpl |before transaction completion
14:31:12.691 D|JdbcTransaction |committed JDBC Connection
14:31:12.691 D|JdbcTransaction |re-enabling autocommit
14:31:12.691 T|TransactionCoordinatorImpl |after transaction completion
14:31:12.707 T|SessionImpl |after transaction completion
14:31:12.707 T|HibernateTransactionManager |Triggering afterCommit synchronization
14:31:12.707 T|HibernateTransactionManager |Triggering afterCompletion synchronization
14:31:12.707 T|TransactionSynchronizationManager |Clearing transaction synchronization
14:31:12.707 T|TransactionSynchronizationManager |Removed value [org.springframework.orm.hibernate4.SessionHolder#711fbb66] for key [org.hibernate.internal.SessionFactoryImpl#5e2ed6a9] from thread [org.springframework.scheduling.quartz.SchedulerFactoryBean#0_Worker-7]
14:31:12.707 T|TransactionSynchronizationManager |Removed value [org.springframework.jdbc.datasource.ConnectionHolder#67914078] for key [org.springframework.jdbc.datasource.DriverManagerDataSource#7bc247d0] from thread [org.springframework.scheduling.quartz.SchedulerFactoryBean#0_Worker-7]
14:31:12.707 D|HibernateTransactionManager |Closing Hibernate Session [SessionImpl(PersistenceContext[entityKeys=[EntityKey[com.polling.entity.DocumentFile#273], EntityKey[com.polling.entity.DocumentGroup#107], EntityKey[com.polling.entity.DocumentFile#275]],collectionKeys=[CollectionKey[com.polling.entity.DocumentFile.docgroups#275], CollectionKey[com.polling.entity.DocumentGroup.files#107], CollectionKey[com.polling.entity.DocumentFile.docgroups#273]]];ActionQueue[insertions=org.hibernate.engine.spi.ExecutableList#2a6f7180 updates=org.hibernate.engine.spi.ExecutableList#7a84a043 deletions=org.hibernate.engine.spi.ExecutableList#1935cd8c orphanRemovals=org.hibernate.engine.spi.ExecutableList#1b49af42 collectionCreations=org.hibernate.engine.spi.ExecutableList#291240d collectionRemovals=org.hibernate.engine.spi.ExecutableList#6d5d2cc collectionUpdates=org.hibernate.engine.spi.ExecutableList#40025295 collectionQueuedOps=org.hibernate.engine.spi.ExecutableList#587bd507 unresolvedInsertDependencies=UnresolvedEntityInsertActions[]])] after transaction
14:31:12.707 T|SessionImpl |Closing session
14:31:12.707 I|StatisticalLoggingSessionEventListener |Session Metrics {
36322379 nanoseconds spent acquiring 1 JDBC connections;
0 nanoseconds spent releasing 0 JDBC connections;
16153296 nanoseconds spent preparing 2 JDBC statements;
20467177 nanoseconds spent executing 2 JDBC statements;
0 nanoseconds spent executing 0 JDBC batches;
0 nanoseconds spent performing 0 L2C puts;
0 nanoseconds spent performing 0 L2C hits;
0 nanoseconds spent performing 0 L2C misses;
7830765 nanoseconds spent executing 1 flushes (flushing a total of 3 entities and 3 collections);
85953666 nanoseconds spent executing 2 partial-flushes (flushing a total of 2 entities and 2 collections)
}
Have found the crux of my problem. Wasnt related to transactions at all. By mistake I had added updatable=false to my entity class property(active) get accessor. Sorry for the trouble. Really a very elementary mistake!!! Apologies to all that have spent time on this..
session.saveOrUpdate(Object) method only converts any transient object into persistence object, means object associates with current hibernate session. When current hibernate session will be flushed or hibernate transaction will be committed then only actual query will run to store object data into the database.
Hibernate saveOrUpdate(Object) works like above comment. I don't know much about Spring.
I hope above description will work for you.
Example code : Hibernate
Session session = sessionFactory.getCurrentSession();
session.setFlush(FlushMode.COMMIT);// Session will be flushed when transation.commit will be called
Transaction tx = session.beginTransaction();
session.saveOrUpdate(Object obj);
tx.commit();// this line will run query to map your object on database
OR
Session session = sessionFactory.getCurrentSession();
session.setFlush(FlushMode.MANUAL);// Session will be only ever flushed when session.flush() will be explicitely called by aaplication
Transaction tx = session.beginTransaction();
session.saveOrUpdate(Object obj);
session.flush();// this line will run query to map your object on database
tx.commit();
Thanks
What you've written so far seems that your Spring TransactionManagement configuration is wrong.
A simple solution if you don't want to configure aspects is to use a programmatic approach using the Spring Framework TransactionTemplate
public class DMSDBDetectionJob {
private final TransactionTemplate transactionTemplate;
public DMSDBDetectionJob(PlatformTransactionManager transactionManager) {
Assert.notNull(transactionManager, "The 'transactionManager' argument must not be null.");
this.transactionTemplate = new TransactionTemplate(transactionManager);
// optional configuration of the Transaction like timeout
// this.transactionTemplate.setTimeout(30); // 30 seconds
}
public void deleteDBMaster() {
transactionTemplate.execute(new TransactionCallbackWithoutResult() {
protected void doInTransactionWithoutResult(TransactionStatus status) {
deleteDBMasterImpl();
}
});
}
private void deleteDBMasterImpl() {
List<DocumentFile> strayFiles = documentDaoImpl.getStrayDocumentFiles();
try
{
if (strayFiles.size() > 0)
{
//delete
strayFiles = documentDaoImpl.softDelete(strayFiles, DocumentFile.class);
documentDaoImpl.saveOrUpdateAll(strayFiles);
...
}
} catch (...) {...}
}
Your Spring Configuration should have at least two entries like:
<!-- PlatformTransactionManager which are going to drive transaction-->
<bean id="transactionManager" class="org.springframework.jdbc.datasource.DataSourceTransactionManager">
<property name="dataSource" ref="dataSource"></property>
</bean>
<!-- Instance of transaction template -->
<bean id="transactionTemplate" class="org.springframework.transaction.support.TransactionTemplate">
<property name="transactionManager" ref="transactionManager"></property>
</bean>

TransactionTemplate and TransactionManager connection objects

The following code in my DAO works perfectly fine.
public void insert(final Person person) {
transactionTemplate.execute(new TransactionCallback<Void>() {
public Void doInTransaction(TransactionStatus txStatus) {
try {
getJdbcTemplate().execute("insert into person(username, password) values ('" + person.getUsername() + "','" + person.getPassword() + "')");
} catch (RuntimeException e) {
txStatus.setRollbackOnly();
throw e;
}
return null;
}
});
}
Following is my spring config.
<bean id="derbyds" class="org.apache.commons.dbcp.BasicDataSource">
<property name="driverClassName" value="org.apache.derby.jdbc.EmbeddedDriver" />
<property name="username" value="app" />
<property name="password" value="app" />
<property name="url" value="jdbc:derby:mytempdb" />
</bean>
<bean id="persondaojdbc" class="com.napp.dao.impl.PersonDaoJdbcImpl">
<property name="dataSource" ref="derbyds" />
<property name="transactionTemplate">
<bean class="org.springframework.transaction.support.TransactionTemplate">
<property name="transactionManager" ref="transactionManager" />
</bean>
</property>
</bean>
<bean id="transactionManager" class="org.springframework.jdbc.datasource.DataSourceTransactionManager">
<property name="dataSource" ref="derbyds"/>
</bean>
What i wanted to know is how does the
<bean id="persondaojdbc" class="com.napp.dao.impl.PersonDaoJdbcImpl">
<property name="dataSource" ref="derbyds" />
<property name="transactionTemplate">
<bean class="org.springframework.transaction.support.TransactionTemplate">
<property name="transactionManager" ref="transactionManager" />
</bean>
</property>
</bean>
<bean id="transactionManager" class="org.springframework.jdbc.datasource.DataSourceTransactionManager">
<property name="dataSource" ref="derbyds"/>
</bean>
Now, its imperative that both the TransactionManager and the code (in my case jdbc template) operate on the same connection. I am assuming both of them are getting the Connection objects from the DataSource. DataSource pools connections and its a chance when you call getConnection multiple times, you will get different Connection obejcts. How does spring make sure that the TransactionManager and JdbcTemplate end up getting the same connection objects. My understanding is that, if that doesn't happen, rollbacks, or commits wont work, correct? Could someone throw more light on this.
If you look at the code for JdbcTemplate (one of the execute(...) methods) you will see
Connection con = DataSourceUtils.getConnection(getDataSource());
Which tries to retrieve a Connection from a ConnectionHolder registered with a TransactionSynchronizationManager.
If there is no such object, it just gets a connection from the DataSource and registers it (if it is in a transactional environment, ie. you have a transaction manager). Otherwise, it immediately returns the registered object.
This is the code (stripped of logs and stuff)
ConnectionHolder conHolder = (ConnectionHolder) TransactionSynchronizationManager.getResource(dataSource);
if (conHolder != null && (conHolder.hasConnection() || conHolder.isSynchronizedWithTransaction())) {
conHolder.requested();
if (!conHolder.hasConnection()) {
conHolder.setConnection(dataSource.getConnection());
}
return conHolder.getConnection();
}
// Else we either got no holder or an empty thread-bound holder here.
Connection con = dataSource.getConnection();
// flag set by the TransactionManager
if (TransactionSynchronizationManager.isSynchronizationActive()) {
// Use same Connection for further JDBC actions within the transaction.
// Thread-bound object will get removed by synchronization at transaction completion.
ConnectionHolder holderToUse = conHolder;
if (holderToUse == null) {
holderToUse = new ConnectionHolder(con);
}
else {
holderToUse.setConnection(con);
}
holderToUse.requested();
TransactionSynchronizationManager.registerSynchronization(
new ConnectionSynchronization(holderToUse, dataSource));
holderToUse.setSynchronizedWithTransaction(true);
if (holderToUse != conHolder) {
TransactionSynchronizationManager.bindResource(dataSource, holderToUse);
}
}
return con;
You'll notice that the JdbcTemplate tries to
finally {
DataSourceUtils.releaseConnection(con, getDataSource());
}
release the Connection, but this only happens if you're in a non-transactional environment, ie.
if it is not managed externally (that is, not bound to the thread).
Therefore, in a transactional world, the JdbcTemplate will be reusing the same Connection object.

transactions not working with Spring 3.1 – H2 – junit 4– hibernate 3.2

I have the following test..
#RunWith(SpringJUnit4ClassRunner.class)
#ContextConfiguration(locations = {"/schedule-agents-config-context.xml"})
#TransactionConfiguration(transactionManager = "transactionManager", defaultRollback = true)
#Transactional
public class H2TransactionNotWorkingTest extends SubmitAgentIntegratedTestBase {
private static final int FIVE_SUBMISSIONS = 5;
#Autowired
private ApplicationSubmissionInfoDao submissionDao;
private FakeApplicationSubmissionInfoRepository fakeRepo;
#Before
public void setUp() {
fakeRepo = fakeRepoThatNeverFails(submissionDao, null);
submitApplication(FIVE_SUBMISSIONS, fakeRepo);
}
#Test
#Rollback(true)
public void shouldSaveSubmissionInfoWhenFailureInDatabase() {
assertThat(fakeRepo.retrieveAll(), hasSize(FIVE_SUBMISSIONS));
}
#Test
#Rollback(true)
public void shouldSaveSubmissionInfoWhenFailureInXmlService() {
assertThat(fakeRepo.retrieveAll().size(), equalTo(FIVE_SUBMISSIONS));
}
}
...and the following config...
<jdbc:embedded-database id="dataSource" type="H2">
<jdbc:script location="classpath:/db/h2-schema.sql" />
</jdbc:embedded-database>
<tx:annotation-driven transaction-manager="transactionManager"/>
<bean id="transactionManager" class="org.springframework.jdbc.datasource.DataSourceTransactionManager">
<property name="dataSource" ref="dataSource"/>
</bean>
<bean id="transactionalSessionFactory"
class="org.springframework.orm.hibernate3.annotation.AnnotationSessionFactoryBean">
<property name="dataSource" ref="dataSource"/>
<property name="hibernateProperties">
<props>
<prop key="hibernate.dialect">org.hibernate.dialect.H2Dialect</prop>
<prop key="hibernate.show_sql">false</prop>
<prop key="hibernate.cache.use_second_level_cache">false</prop>
<prop key="hibernate.cache.use_query_cache">false</prop>
</props>
</property>
<property name="namingStrategy">
<bean class="org.hibernate.cfg.ImprovedNamingStrategy"/>
</property>
<property name="configurationClass" value="org.hibernate.cfg.AnnotationConfiguration"/>
<property name="packagesToScan" value="au.com.mycomp.life.snapp"/>
</bean>
<bean id="regionDependentProperties" class="org.springframework.core.io.ClassPathResource">
<constructor-arg value="region-dependent-service-test.properties"/>
</bean
>
I have also set auto commit to false in the sql script
SET AUTOCOMMIT FALSE;
There are not REQUIRES_NEW in the code.
Why is the rollback not working in the test?
Cheers
Prabin
I have faced the same problem but I have finally solved it albeit I don't use Hibernate (shouldn't really matter).
The key item making it work was to extend the proper Spring unit test class, i.e. AbstractTransactionalJUnit4SpringContextTests. Note the "Transactional" in the class name. Thus the skeleton of a working transactional unit test class looks like:
#ContextConfiguration(locations = {"classpath:/com/.../testContext.xml"})
public class Test extends AbstractTransactionalJUnit4SpringContextTests {
#Test
#Transactional
public void test() {
}
}
The associated XML context file has the following items contained:
<jdbc:embedded-database id="dataSource" type="H2" />
<tx:annotation-driven transaction-manager="transactionManager"/>
<bean id="transactionManager" class="org.springframework.jdbc.datasource.DataSourceTransactionManager">
<property name="dataSource" ref="dataSource"></property>
</bean>
Using this setup the modifications by each test method is properly rolled back.
Regards, Ola
I'm experiencing similar problems, I'm also using TestNG + Spring test support and Hibernate. What happens is that Hibernate disables autocommit on the connection before the transaction begins and it remembers the original autocommit setting:
org.hibernate.engine.transaction.internal.jdbc#JdbcTransaction:
#Override
protected void doBegin() {
try {
if ( managedConnection != null ) {
throw new TransactionException( "Already have an associated managed connection" );
}
managedConnection = transactionCoordinator().getJdbcCoordinator().getLogicalConnection().getConnection();
wasInitiallyAutoCommit = managedConnection.getAutoCommit();
LOG.debugv( "initial autocommit status: {0}", wasInitiallyAutoCommit );
if ( wasInitiallyAutoCommit ) {
LOG.debug( "disabling autocommit" );
managedConnection.setAutoCommit( false );
}
}
catch( SQLException e ) {
throw new TransactionException( "JDBC begin transaction failed: ", e );
}
isDriver = transactionCoordinator().takeOwnership();
}
Later on, after rolling back the transaction, it will release the connection. Doing so hibernate will also restore the original autocommit setting on the connection (so that others who might be handed out the same connection start with the original setting). However, setting the autocommit during a transaction triggers an explicit commit, see JavaDoc
In the code below you can see this happening. The rollback is issued and finally the connection is released in releaseManagedConnection. Here the autocommit will be re-set which triggers a commit:
org.hibernate.engine.transaction.internal.jdbc#JdbcTransaction:
#Override
protected void doRollback() throws TransactionException {
try {
managedConnection.rollback();
LOG.debug( "rolled JDBC Connection" );
}
catch( SQLException e ) {
throw new TransactionException( "unable to rollback against JDBC connection", e );
}
finally {
releaseManagedConnection();
}
}
private void releaseManagedConnection() {
try {
if ( wasInitiallyAutoCommit ) {
LOG.debug( "re-enabling autocommit" );
managedConnection.setAutoCommit( true );
}
managedConnection = null;
}
catch ( Exception e ) {
LOG.debug( "Could not toggle autocommit", e );
}
}
This should not be a problem normally, because afaik the transaction should have ended after the rollback. But even more, if I issue a commit after a rollback it should not be committing any changes if there were no changes between the rollback and the commit, from the javadoc on commit:
Makes all changes made since the previous commit/rollback permanent
and releases any database locks currently held by this Connection
object. This method should be used only when auto-commit mode has been
disabled.
In this case there were no changes between rollback and commit, since the commit (triggered indirectly by re-setting autocommit) happens only a few statements later.
A work around seems to be to disable autocommit. This will avoid restoring autocommit (since it was not enabled in the first place) and thus prevent the commit from happening. You can do this by manipulating the id for the embedded datasource bean. The id is not only used for the identification of the datasource, but also for the databasename:
<jdbc:embedded-database id="dataSource;AUTOCOMMIT=OFF" type="H2"/>
This will create a database with name "dataSource". The extra parameter will be interpreted by H2. Spring will also create a bean with name "dataSource;AUTOCOMMIT=OFF"". If you depend on the bean names for injection, you can create an alias to make it cleaner:
<alias name="dataSource;AUTOCOMMIT=OFF" alias="dataSource"/>
(there isn't a cleaner way to manipulate the embedded-database namespace config, I wish Spring team would have made this a bit better configurable)
Note: disabling the autocommit via the script (<jdbc:script location="...") might not work, since there is no guarantee that the same connection will be re-used for your test.
Note: this is not a real fix but merely a workaround. There is still something wrong that cause the data to be committed after a rollback occured.
----EDIT----
After searching I found out the real problem. If you are using HibernateTransactionManager (as I was doing) and you use your database via the SessionFactory (Hibernate) and directly via the DataSource (plain JDBC), you should pass both the SessionFactory and the DataSource to the HibernateTransactionManager. From the Javadoc:
Note: To be able to register a DataSource's Connection for plain JDBC code, this instance >needs to be aware of the DataSource (setDataSource(javax.sql.DataSource)). The given >DataSource should obviously match the one used by the given SessionFactory.
So eventually I did this:
<bean id="transactionManager" class="org.springframework.orm.hibernate4.HibernateTransactionManager">
<property name="sessionFactory" ref="sessionFactory" />
<property name="dataSource" ref="dataSource" />
</bean>
And everything worked for me.
Note: the same goes for JpaTransactionManager! If you both use the EntityManager and perform raw JDBC access using the DataSource, you should supply the DataSource separately next to he EMF. Also don't forget to use DataSourecUtils to obtain a connection (or JDBCTemplate which uses DataSourceUtils internally to obtain the connection)
----EDIT----
Aight, while the above did solve my problem, it is not the real cause after all :)
In normal cases when using Spring's LocalSessionFactoryBean, setting the datasource will have no effect since it's done for you.
If the SessionFactory was configured with LocalDataSourceConnectionProvider, i.e. by Spring's LocalSessionFactoryBean with a specified "dataSource", the DataSource will be auto-detected: You can still explicitly specify the DataSource, but you don't need to in this case.
In my case the problem was that we created a caching factory bean that extended LocalSessionFactoryBean. We only use this during testing to avoid booting the SessionFactory multiple times. As told before, Spring test support does boot multiple application contexts if the resource key is different. This caching mechanism mitigates the overhead completely and ensures only 1 SF is loaded.
This means that the same SessionFactory is returned for different booted application contexts. Also, the datasource passed to the SF will be the datasource from the first context that booted the SF. This is all fine, but the DataSource itself is a new "object" for each new application context. This creates a discrepancy:
The transaction is started by the HibernateTransactionManager. The datasource used for transaction synchronization is obtained from the SessionFactory (so again: the cached SessionFactory with the DataSource instance from the application context the SessionFactory was initially loaded from). When using the DataSource in your test (or production code) directly, you'll be using the instance belonging to the app context active at that point. This instance does not match the instance used for the transaction synchronization (extracted from the SF). This result into problems as the connection obtained will not be properly participating in the transaction.
By explicitly setting the datasource on the transactionmanager this appeared to be solved since the post initialization will not obtain the datasource from the SF but use the injected one instead. The appropriate way for me was to adjust the caching mechanism and replace the datasource in the cached SF with the one from the current appcontext each time the SF was returned from cache.
Conclusion: you can ignore my post:) as long as you're using HibernateTransactionManager or JtaTransactionManager in combination with some kind of Spring support factory bean for the SF or EM you should be fine, even when mixing vanilla JDBC with Hibernate. In the latter case don't forget to obtain connections via DataSourceUtils (or use JDBCTemplate).
Try this:
remove the org.springframework.jdbc.datasource.DataSourceTransactionManager
<bean id="transactionManager" class="org.springframework.jdbc.datasource.DataSourceTransactionManager">
<property name="dataSource" ref="dataSource"/>
</bean>
and replace it with the org.springframework.orm.jpa.JpaTransactionManager
<bean id="transactionManager" class="org.springframework.orm.jpa.JpaTransactionManager">
<property name="dataSource" ref="dataSource"/>
</bean>
or you inject an EntityManagerFactory instead ...
<bean id="transactionManager" class="org.springframework.orm.jpa.JpaTransactionManager">
<property name="entityManagerFactory" ref="entityManagerFactory" />
</bean>
you need an EntityManagerFactory then, like the following
<bean id="entityManagerFactory"
class="org.springframework.orm.jpa.LocalContainerEntityManagerFactoryBean">
<property name="dataSource" ref="dataSource" />
<property name="jpaVendorAdapter">
<bean id="jpaAdapter"
class="org.springframework.orm.jpa.vendor.HibernateJpaVendorAdapter">
<property name="showSql" value="true" />
<property name="generateDdl" value="true" />
</bean>
</property>
</bean>
You haven't shown all the pieces to the puzzle. My guess at this point would be that your ApplicationSubmissionInfoDao is transactional and is committing on its own, though I'd think that would conflict with the test transactions if everything were configured properly. To get more of an answer, ask a more complete question. The best thing would be to post an SSCCE.
Thanks Ryan
The test code is something like this.
#Test
#Rollback(true)
public void shouldHave5ApplicationSubmissionInfo() {
for (int i = 0; i < 5; i++) {
hibernateTemplate.saveOrUpdate(new ApplicationSubmissionInfoBuilder()
.with(NOT_PROCESSED)
.build());
}
assertThat(repo.retrieveAll(), hasSize(5));
}
#Test
#Rollback(true)
public void shouldHave5ApplicationSubmissionInfoAgainButHas10() {
for (int i = 0; i < 5; i++) {
hibernateTemplate.saveOrUpdate(new ApplicationSubmissionInfoBuilder()
.with(NOT_PROCESSED)
.build());
}
assertThat(repo.retrieveAll(), hasSize(5));
}
I figure out that embedded DB define using jdbc:embedded-database don't have transaction support. When I used commons DBCP to define the datasource and set default auto commit to false, it worked.
<bean id="dataSource" class="org.apache.commons.dbcp.BasicDataSource" scope="singleton">
<property name="driverClassName" value="org.h2.Driver" />
<property name="url" value="jdbc:h2:~/snappDb"/>
<property name="username" value="sa"/>
<property name="password" value=""/>
<property name="defaultAutoCommit" value="false" />
<property name="connectionInitSqls" value=""/>
</bean>
None of the above worked for me!
However, the stack i am using is [spring-test 4.2.6.RELEASE, spring-core 4.2.6.RELEASE, spring-data 1.10.1.RELEASE]
The thing is, using any unit test class annotated with [SpringJUnit4ClassRunner.class] will result in an auto-rollback functionality by spring library design
check ***org.springframework.test.context.transaction.TransactionalTestExecutionListener*** >> ***isDefaultRollback***
To overcome this behavior just annotate the unit test class with
#Rollback(value = false)

BasicDataSource with JDBCTemplate not pooling connections as expected

I am trying to use BasicDataSource to pool connections with JDBCTemplate in a spring application. From everything I've read, this should be really simple: Just configure the BasicDataSource in XML, inject the data source into a bean, and in the setter method, create a new JDBCTemplate.
When I did this, I noticed my performance was terrible. So then I switched to Spring's SingleConnectionDataSource, just to see what would happen, and my performance got much better. I started investigating with a profiler tool, and I noticed that when using BasicDataSource, a new connection was being created for every query.
Investigating further, I can see where the connection is being closed after the query is finished. Specifically in Spring's DataSourceUtil class:
public static void doReleaseConnection(Connection con, DataSource dataSource) throws SQLException {
if (con == null) {
return;
}
if (dataSource != null) {
ConnectionHolder conHolder = (ConnectionHolder) TransactionSynchronizationManager.getResource(dataSource);
if (conHolder != null && connectionEquals(conHolder, con)) {
// It's the transactional Connection: Don't close it.
conHolder.released();
return;
}
}
// Leave the Connection open only if the DataSource is our
// special SmartDataSoruce and it wants the Connection left open.
if (!(dataSource instanceof SmartDataSource) || ((SmartDataSource) dataSource).shouldClose(con)) {
logger.debug("Returning JDBC Connection to DataSource");
con.close();
}
}
The thing that I notice is there is some special logic for 'SmartDataSource' which leaves the connection open. This partially explains the behavior I was seeing: Since SingleConnectionDataSource implements SmartDataSource, the connection is not closed. However, I thought by using BasicDataSource, the close() method on the connection would just return the connection to the pool. However, when I look at what is happening in my profiler, the close method is actually being called on my sybase connection: not any kind of 'Pooled Connection Wrapper' like I would expect to see.
One last thing (this is what I'm going to investigate now): I use TransactionTemplate for some of my queries (involving commits to the database), but simple queries are not inside a transactionTemplate. I don't know if that has anything to do with the problem or not.
EDIT 1:
Ok finally got some more time to investigate after getting pulled off the project a bit and, here is a very simple test that shows the problem
public class DBConnectionPoolTest {
#Autowired
#Qualifier("myDataSource")
private DataSource dataSource;
#Test
public void test() throws Exception{
JdbcTemplate template = new JdbcTemplate(dataSource);
StopWatch sw = new StopWatch();
sw.start();
for(int i=0; i<1000; i++){
template.queryForInt("select count(*) from mytable");
}
sw.stop();
System.out.println("TIME: " + sw.getTotalTimeSeconds() + " seconds");
}}
Here are my two datasource configurations:
<bean id="myDataSource" class="org.springframework.jdbc.datasource.SingleConnectionDataSource">
<property name="driverClassName" value="${db.driver}" />
<property name="url" value="${db.url}" />
<property name="username" value="${db.username}" />
<property name="password" value="${db.password}" />
</bean>
<bean id="myDataSource" class="org.apache.commons.dbcp.BasicDataSource">
<property name="driverClassName" value="${db.driver}" />
<property name="url" value="${db.url}" />
<property name="username" value="${db.username}" />
<property name="password" value="${db.password}" />
</bean>
When I run the test with the first configuration, it takes about 2.1 seconds. When I run it with the second configuration, it takes about 4.5 seconds. I have tried various parameters on BasicDataSource, such as setting maxActive=1 and testOnBorrow=false, but nothing makes a difference.
I think the problem in my case was that my jdbc libraries for sybase were outdated.

Resources