CODEWITHSUNDEEP
springtransactionsannotationsdao
cherouvim
cherouvim

Reputation: 31903

Spring @Transactional wrapping 2 methods

I'm a Spring newby. I use the @Transactional annotation for my dao methods:

@Transactional
public Person getById(long id) {
    return new Person(jdbcTemplate.queryForMap(...));
}

@Transactional
public void save(Person person) {
    jdbcTemplate.update(...);
}

and I've set up the transaction manager like this:

<tx:annotation-driven transaction-manager="txManager" />
<bean id="txManager" class="org.springframework.jdbc.datasource.DataSourceTransactionManager">
    <property name="dataSource" ref="dataSource" />
</bean>

The problem is that when my client code calls dao.save(..) and then dao.getById(4) these happen in two separate transactions. How is it possible to wrap those 2 calls in the same database transaction? Ideally without doing it in a programmatic way.

thanks

Upvotes: 4

Views: 3723

Answers (3)

Rakesh Goyal
Rakesh Goyal

Reputation: 3231

It is bad practice to put transactional attributes in DAO layer. Also, I am not sure why do you require transaction for getById method. Even if you want to use transaction then you need to specify propagation behaviour as REQUIRES_NEW for save and getById method.

Upvotes: 5

Pierre Gardin
Pierre Gardin

Reputation: 684

@Transactional(propagation = REQUIRES_NEW, readOnly = false)
public Person saveAndGetById(Person person, long id) {
    save(person);
    return getById(id);
}

@Transactional(propagation = REQUIRED)
public Person getById(long id) {
    return new Person(jdbcTemplate.queryForMap(...));
}

@Transactional(propagation = REQUIRED, readOnly = false)
public void save(Person person) {
    jdbcTemplate.update(...);
}

However, the best thing would be to have the "save" method return an ID, because it is hard to know beforehand which ID the Person will have once persisted.

Upvotes: 4

Vadim Fedorov
Vadim Fedorov

Reputation: 463

Good practice in this case would be marking service method which invokes both these DAO methods as @Transactional. The case was clearly discussed here.

Upvotes: 4

Related Questions