TransactionTemplate vs JdbcTemplate - spring

The Spring framework provides two means of programmatic transaction management:
Using the TransactionTemplate.
Using a PlatformTransactionManager implementation directly.
The above is described here: http://static.springsource.org/spring/docs/2.0.8/reference/transaction.html
The Spring site hasnot mentioned JdbcTemplate here. As per my understanding JdbcTemplate also manages the transaction internally and this is all done in programme too.
So what's the basic difference between TransactionTemplate and JdbcTemplate?

JdbcTemplate is not a transaction manager. It's merely a helper class for native JDBC operations:
This is the central class in the JDBC core package. It simplifies the use of JDBC and helps to avoid common errors. It executes core JDBC workflow, leaving application code to provide SQL and extract results. This class executes SQL queries or updates, initiating iteration over ResultSets and catching JDBC exceptions and translating them to the generic, more informative exception hierarchy defined in the org.springframework.dao package.
TransactionTemplate by the way is also not a transaction manager, it's a
Template class that simplifies programmatic transaction demarcation and transaction exception handling.
The PlatformTransactionManager (and other subclasses of AbstractPlatformTransactionManager) is a transaction manager, as in it
determines if there is an existing transaction;
applies the appropriate propagation behavior;
suspends and resumes transactions if necessary;
checks the rollback-only flag on commit;
applies the appropriate modification on rollback (actual rollback or setting rollback-only);
triggers registered synchronization callbacks (if transaction synchronization is active).
So this class is responsible for the actual transaction handling, as opposed to the TransactionTemplate, which is to be used if you instead of declarative transaction handling you want to implement it programmetically. (see this blog, though quite outdated, you will see the difference between declarative and manual)
Quotes from Spring 3 Reference.
Note: Throughout the Spring Framework you will find other *Template classes as well: HibernateTemplate, JmsTemplate etc. They all follow the same pattern: template classes which radically reduce the amount of code you need to write, because all the so-called boilerplate code will be handled by them. Example (from here):
Without JdbcTemplate:
private DataSource dataSource;
public void setDataSource(DataSource dataSource) {
this.dataSource = dataSource;
}
public void insert(Customer customer){
String sql = "INSERT INTO CUSTOMER " +
"(CUST_ID, NAME, AGE) VALUES (?, ?, ?)";
Connection conn = null;
try {
conn = dataSource.getConnection();
PreparedStatement ps = conn.prepareStatement(sql);
ps.setInt(1, customer.getCustId());
ps.setString(2, customer.getName());
ps.setInt(3, customer.getAge());
ps.executeUpdate();
ps.close();
} catch (SQLException e) {
throw new RuntimeException(e);
} finally {
if (conn != null) {
try {
conn.close();
} catch (SQLException e) {}
}
}
}
And with JdbcTemplate:
private DataSource dataSource;
private JdbcTemplate jdbcTemplate;
public void setDataSource(DataSource dataSource) {
this.dataSource = dataSource;
}
public void insert(Customer customer){
String sql = "INSERT INTO CUSTOMER " +
"(CUST_ID, NAME, AGE) VALUES (?, ?, ?)";
jdbcTemplate = new JdbcTemplate(dataSource);
jdbcTemplate.update(sql, new Object[] { customer.getCustId(),
customer.getName(),customer.getAge()
});
}

Related

Why hibernate is saving values without transaction?

i'm using spring boot(2.1.4) with hibernate(5.3.9).
public class BaseDao{
#Autowired
private SessionFactory sessionFactory;
private Session session;
private Transaction transaction;
#Autowired
private EntityManagerFactory entityManagerFactory;
#PersistenceContext
private EntityManager entityManager;
public SessionFactory getSessionFactory() {
return sessionFactory;
}
public EntityManagerFactory getEntityManagerFactory() {
return entityManagerFactory;
}
public EntityManager getEntityManager() {
return entityManager;
}
public Session getSession() throws Exception{
if(session == null) {
session = getSessionFactory().openSession();
}
if(transaction == null) {
transaction = session.beginTransaction();
}
return session;
}
public void commit() throws Exception{
if(transaction != null) {
transaction.commit();
transaction = null;
}
if(session != null) {
session.close();
session = null;
}
}
public void rollback() throws Exception{
if(transaction != null) {
transaction.rollback();
transaction = null;
}
if(session != null) {
session.close();
session = null;
}
}
protected void save(Object object) throws Exception {
getSessionFactory().openSession().save(object); //saves data in db
getSession().save(object); //is not saving data
}
getSessionFactory().openSession().save(object); this code is saving data to db even without commit
getSession().save(object); this code required commit to be called as txn is created but not commited
hibernate log
i see below log for both the line of code
insert
into
TEST_ENTITY
(CREATED_BY, CREATED_DATE, ENABLED, LAST_MODIFIED_BY, LAST_MODIFIED_DATE, NAME)
values
(?, ?, ?, ?, ?, ?)
i have few questions on this behavior.
I know write operation will not happen without commit, so any idea what is wrong here or what causing commit in first scenario ?
Is it ok to use above code i.e. first scenario ?
If first approach is not right then do i need to create and commit txn for each object, any better approach so that even if i have to commit txn, i don't want to replicate the txn.commit() in every new method i write in BaseDao.java i.e. say i have create(), update(),delete() methods can i move this txn.commit() out of methods ?
Few places i'm using spring data jpa for fetching/saving record (given below), how txn is being handled in spring data jpa ? any references ?
#Repository
public interface TestEntitytRepo extends JpaRepository<TestEntity, Long> {
...
}
Please let me know if i missed any details to capture here.
Thanks in advance.
In hibernate, the Save() method stores an object into the database. It will Persist the given transient instance, first assigning a generated identifier. It returns the id of the entity created. When a session in hibernate is created using SessionFactory.openSession(), no transaction is created, so all the operations are executed outside of the transaction context !! In order to ensure the data gets saved into the database, a new transaction needs to be created.
I am a bit skeptical about the behaviors explained by you above. Seems like auto-commit option is enabled. If so, then this is not an issue as save() method is done, commit automatically happens backstage !!

Spring #transactional with #async Timeout value is not working

I have created an asynchronous service for a long running stored procedure call. Things work good but the transaction is not getting timed out after the specified value given in the timeout attribute of the transactional annotation..The structure of the code is given below (not the real one...just skeleton...ignore semantics/syntax)
//asynchronous service
#override
#async("myCustomTaskExecutor")
#Transactional(rollbackfor=Exception.class,timeout=600)
public void serviceMethod(){
//repository method is invoked.
repository.callStoredProcedure();
}
//Repository method in the Repository class
#Transactional(rollbackfor=Exception.class,timeout=600)
public void callStoredProcedure(){
//Stored procedure is called from the private method using hibernate doWork implementation.
privateCallmethod();
}
private void privateCallmethod() throws ApplicationException{
Session session = null;
try{
session = entityManager.unwrap(Session.class);
session.doWork(new Work(){
#Override
public void execute(Connection connection) throws SQLException {
OracleCallableStatement statement =null;
try{
//using hibernate 4.x and ref cursors are used...so went on with this approach..
//suggest if there is some better approach.
String sqlString =“{begin storProcName(?,?)}”;
statement = connection.prepareCall(sqlString);
statement.setInt(1,5);
statement.setString(2,“userName5”);
statement.executeUpdate();
}
catch(Exception e){
throw RunTimeException(e.getMessage);
}
finally{
if(statement != null)
statement.close();
}
}
}
});
}
catch(Exception e){
throw ApplicationException(e.getMessage);
}
//Not using Final block to close the session.Is it an issue ?
}
delay is happening in the stored procedure side(Thread.sleep(700) are not used) yet transaction is not timed out...
Questions :
I guess #Transactional is enough on the service method alone...give little bit insight on correct approach of using #Transactional annotation
for this code setup.
Will the #Transactional works for the JDBC calls inside the doWork Interface implementation...is that whats the issue is ?
Some article suggest to use oracle.jdbc.readTimeout or setQueryTimeout in the CallableStatement... Is it the right way to achieve this.
Kindly point out the mistakes and explain the causes
If #Transactional Annotated method is not the entry point to the class, it will not be transactional unless you enable load time weaving (Spring default is Compile time weaving) https://stackoverflow.com/a/17698587/6785908
You should invoke callStoredProcedure() from outside this class, then it will be transactional. If you invoke serviceMethod() which in turn invokes callStoredProcedure(), then it will not be transactional
I used setQueryTimeout() approach to resolve the issue as #Transactional timeout does not work with the hibernate dowork() method...I guess its due to the hibernate work executes in different thread and it low level JDBC methods to invoke the store procedures...
NOTE: This particular application uses very spring 3.x version and hibernate 4.x with JPA 2.0 spec...little outdated versions

what is the purpose of setNestedTransactionAllowed in JpaTransactionManager

I use the spring boot 1.5.2 RELEASE.
JpaTransactionManager txManager = new JpaTransactionManager();
txManager.setEntityManagerFactory(ptvEntityManagerFactory);
txManager.setDataSource(ds);
txManager.setJpaDialect(hibernateDialect);
//txManager.setNestedTransactionAllowed(true);
so what does this NestedTransactionAllowed really do?
I create code like this:
#Transactional
public void testNestTransaction() {
saveToRepository()
saveToJdbcTemplate();
throw new RuntimeException();
}
#Transactional
private void saveToRepository() {
employeeRepository.save(new MyEntity(xxx,xx,xx));
}
private void saveToJdbcTemplate() {
transactionTemplate.execute(new TransactionCallbackWithoutResult() {
// the code in this method executes in a transactional context
protected void doInTransactionWithoutResult(TransactionStatus status) {
String sql = "INSERT INTO task (id,create_by,description) VALUES
(?,?,?)";
jdbcTemplate.batchUpdate(sql, new BatchPreparedStatementSetter().....
}
}
Here is the problem. no matter NestedTransactionAllowed is true or false, the runTimeException always rollback both in saveToRepository() and saveToJdbcTemplate(). it default value is false, and there is a chunk of JavaDoc to describ this flag.
But I still do not understand what is the point of the NestedTransactionAllowed??
can you guys helps me with some scenarios to show the difference between this value in true and false?
thanks a lot
BTW: the entity manager is hibernate.
// hibernate adapter
HibernateJpaVendorAdapter vendorAdapter = new HibernateJpaVendorAdapter();
Your setNestedTransactionAllowed is not working as nested transaction support is not available for JpaTransaactionManager. Following excerpt from the official doc -
This transaction manager supports nested transactions via JDBC 3.0
Savepoints. The "nestedTransactionAllowed" flag defaults to false
though, since nested transactions will just apply to the JDBC
Connection, not to the JPA EntityManager and its cached entity objects
and related context. You can manually set the flag to true if you want
to use nested transactions for JDBC access code which participates in
JPA transactions (provided that your JDBC driver supports Savepoints).
Note that JPA itself does not support nested transactions! Hence, do
not expect JPA access code to semantically participate in a nested
transaction.

Save an Object after an error Occured in the current Transaction

Hi i have the following construction, which runs a raw query and then saves the result. But when an exception occoured on the raw queries, i cannot save my Object any more to indicate that an error happened
[c3p0] A PooledConnection that has already signalled a Connection error is still in use!
The classes:
#Service("myService")
#Transactional(propagation = Propagation.REQUIRED)
public class MyService {
cron(){
Job job = myDao.nextJob();
try {
myDao.myFunction(job);
job.setStatus(Status.COMPLETE);
} catch (Exception e) {
job.setStatus(Status.ERROR);
}
myDao.save(job);
}
}
#Repository("myDao")
public class MyDao extends HibernateDaoSupport {
#Autowired
public void setHibernateSessionFactory(#Qualifier("sessionFactory") SessionFactory sessionFactory) {
setSessionFactory(sessionFactory);
}
public void myFunction(final Job job) {
final Session session = getCurrentSession();
session.flush();
session.doWork(new Work() {
#Override
public void execute(Connection con) throws SQLException {
// do something which creates an SQL error
}
}
}
}
what can i do to get a new working session to get my object saved?
1) It looks like you are not releasing the connection to the connection pool after an error, and trying to reuse it.
2) Instead of final Session session = getCurrentSession() create a new session using openSession() as below:
SessionFactory sessionFactory = HibernateUtil.getSessionAnnotationFactory();
final Session session = sessionFactory.openSession();
Try to create new session for each transaction, if you use getCurrentSession and any error occurs or not in the transaction, then the maintainence(closing/flushing etc) of the session object is done by hibernate and not by the programmer. Make use of getCurrentSession for single threaded environment.
3) By default a Connection object is in auto-commit mode, which means that it automatically commits changes after executing each statement. Check whether have you altered its property? Use Connection.commit() to commit the connection.

JMS doesn't rollback XA transaction (or doesn't participate in one)

I'm relatively new to XA transactions. I've been struggling a few days to make a simple XA transaction work to no avail.
First, I tried to use two different databases. I set up 2 XA datasources and had succeeded in rolling back the first database operation when the second fails. So far, so good. But then I tried to replace second datasource with JMS connectionFactory and cannot reproduce the same behavior.
Here's the relevant code:
Database logic:
#Stateless
public class FirstDB implements FirstDBLocal {
#PersistenceContext(unitName = "xaunit")
private EntityManager em;
public void doSomething() {
SomeEntity someEntity = em.find(SomeEntity.class, 1234L);
someEntity.setSomeFlag(false);
}
}
JMS code:
#Stateless
public class SecondJMS implements SecondJMSLocal {
#Resource(mappedName = "java:/JmsXA")
private ConnectionFactory connFactory;
#Resource(mappedName = "queue/Some.Queue")
private Queue q;
#Override
#TransactionAttribute(TransactionAttributeType.MANDATORY)
public void sendMsg() {
Session session = null;
Connection conn = null;
MessageProducer producer = null;
try {
conn = connFactory.createConnection("guest", "guest");
session = conn.createSession(false, Session.AUTO_ACKNOWLEDGE);
producer = session.createProducer(q);
// Not sure if I need this, but I found it in the sample code
conn.start();
TextMessage tm = session.createTextMessage(new Date().toString());
producer.send(tm);
throw new RuntimeException("Fake exception");
} catch (JMSException e) {
e.printStackTrace();
} catch (RuntimeException e) {
e.printStackTrace();
} finally {
// close all resources
}
}
}
The glue code:
#Stateless
public class TestDBandJMS implements TestDBandJMSLocal {
#EJB
private FirstDBLocal firstDBLocal;
#EJB
private SecondJMSLocal secondJMSLocal;
public void doStuff() {
firstDBLocal.doSomething();
secondJMSLocal.sendMsg();
}
}
XA Connection Factory configuration (everything is JBoss default, except for commented out security settings):
<tx-connection-factory>
<jndi-name>JmsXA</jndi-name>
<xa-transaction/>
<rar-name>jms-ra.rar</rar-name>
<connection-definition>org.jboss.resource.adapter.jms.JmsConnectionFactory</connection-definition>
<config-property name="SessionDefaultType" type="java.lang.String">javax.jms.Topic</config-property>
<config-property name="JmsProviderAdapterJNDI" type="java.lang.String">java:/DefaultJMSProvider</config-property>
<max-pool-size>20</max-pool-size>
<!-- <security-domain-and-application>JmsXARealm</security-domain-and-application> -->
<depends>jboss.messaging:service=ServerPeer</depends>
</tx-connection-factory>
I also have very simple MDB which just prints out received message to console (not going to post the code, since it's trivial).
The problem is, when the exception is thrown in JMS code, the message is still received by MDB and SomeEntity is successfully updated in the database code (whereas I expect it to rollback).
Here is the JMS log. One fishy thing that I see there is this:
received ONE_PHASE_COMMIT request
Like I said, I'm not too familiar with XA yet, but I expect to see here TWO_PHASE_COMMIT, because there should be 2 resources which participate in the active transaction.
Any help would be much appreciated.
UPDATE
It worked eventually, after I tried #djmorton's suggestion.
One other important thing to keep in mind when working with JBoss 5.1 is that the lookup name for XA JMS ConnectionFactory is "java:/JmsXA". I tried the same with
#Resource(mappedName = "XAConnectionFactory")
private ConnectionFactory connFactory;
and it didn't work.
You are catching your RuntimeException after throwing it in your sendMsg() method. The Exception will not trigger a transaction rollback unless it is thrown up the stack. When using Container managed transactions, the container adds interceptors to the method calls to setup the transactions and handle rollbacks when unchecked exceptions are thrown. If the exception isn't thrown out of the method the interceptor doesn't know it needs to role the transaction back.
Edit 1:
Note that only a RuntimeException or a subclass of RuntimeException being thrown will cause the transaction to rollback. A checked exception (One that extends Exception rather than RuntimeException) will not cause a rollback unless it is annotated with #ApplicationException(rollback=true).
The other alternative is to inject an EJBContext object, and call .setRollbackOnly() to force the transaction to rollback when the method goes out of scope:
#Stateless
public class SomeEjb {
#Resource
private EJBContext context;
#TransactionAttribute(TransactionAttributeType.MANDATORY)
public void rollMeBack() {
context.setRollbackOnly();
}
}

Resources