Menu
Simplified example:
@Entity
public class Foo {
@Id
@GeneratedValue(strategy = GenerationType.IDENTITY)
private Integer id;
private String bar;
// getters + setters
}
public interface FooRepository extends CrudRepository<Foo, Integer> {
}
@Service
public class FooService {
private final FooRepository repository;
public FooService(FooRepository repository) {
this.repository = repository;
}
public Foo save(Foo foo) {
return repository.save(foo);
}
}
Calling fooService.save(myNewFoo) from a controller works, while I would have expected it to fail (if I understand transactions correctly), as no method has been annotated with @Transactional (and I actually would like it to fail). Any idea why this behavior? Who's creating a transaction behing the scene, and how to avoid this?
Additional details:
845
Since your object is already changed within the context of the persistence context and the transaction, the changes are saved to the database even without the need to explicitly call a save method.
CrudRepository's "save" operation commits transaction even if Service does rollback [DATAJPA-219] #631.
Normally, Hibernate holds the persistable state in memory. The process of synchronizing this state to the underlying DB is called flushing. When we use the save() method, the data associated with the save operation won't be flushed to the DB unless, and until, an explicit call to the flush() or commit() method is made.
The save operation performs a merge on the underlying EntityManager . This on its own doesn't perform any SQL but just returns a managed version of the entity. If that isn't already loaded into the EntityManager it might do this or it might identify the entity as a new one and make it a managed entity.
The implementation of CrudRepository#save provided by Spring creates a transaction by default. Please see the documentation for further details.
156
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
