We Keep Coding

How to understand #Transactional with setters in Java?

Following tutorial on Java Spring, I'm trying to understand how does #Transactional work with setters, and from other question/sources, I can't find a beginner-friendly explanation for it.
Let's say I have a user entity with getters and setters:
#Entity
public class User {
// Id set up
private Long id;
private String name;
private String email;
private String password;
// Other constructors, setters and getters
public void setName(String name) {
this.name = name;
}
}
And in the UserService I have a getUserName method:
#Service
public class UserService {
private final UserRepository userRepository;
#Autowired
public UserService(UserRepository userRepository) {
this.userRepository = userRepository;
}
#Transactional
public void getUserName(Long id) {
User user = userRepository.findById(id).orElseThrow();
user.setName("new user name"); // Why will this update db?
}
}
With #Transactional annotated, the setter function does update db, is this the spring way of updating data? Can someone help explain in layman term, how the Transactional work with setters under the hood?
Edit:
Without #Transactional, setter function won't update db, but in
order to mutate db, will have to call userRepository.save(user). And from the video, the instructor simply says the Transactional will handle jpql for us, and use setters along with it to update db.
Resource update:
Spring Transaction Management: #Transactional In-Depth, hope this is helpful.

Firstly, it is the underlying JPA provider (assume it is Hibernate) to be responsible for updating the entity but not Spring. Spring just provides the integration support with Hibernate.
To update an entity loaded from the DB , generally you need to make sure the following happens in order.
Begin a DB transaction
Use EntityManager to load the entity that you want to update.The loaded entity is said to be managed by this EntityManager such that it will keep track all the changes made on its state and will generate the necessary update SQL to update this entity in (4) automatically.
Make some changes to the entity 's state. You can do it through any means such as calling any methods on it , not just restricting to calling it by setter
Flush the EntityManager. It will then generate update SQL and send to DB.
Commit the DB transaction
Also note the followings:
Spring provides #Transactional which is a declarative way to execute (1) and (5) by annotating it to a method.
By default , Hibernate will call (4) automatically before executing (5) such that you do not need to call (4) explicitly.
Spring Data JPA repository internally use EntityManager to load the user. So the user return from the repository will be managed by this EntityManager.
So in short , #Transactional is necessary to update the entity. And updating the entity is nothing to do with setter as it just care if there are state changes on the entity in the end , and you can do it without using setter.

Spring uses Hibernate as ORM under the hood.
When you call userRepository.findById, Hibernate entity manager is called under the hood, it retrieves entity from database and at the same time makes this entity manageable (you can read separately about Hibernate managed entities).
What it means, in a simple words, the Hibernate 'remembers' the reference to this entity in its internal structures, in the so-called session. It, actually, 'remembers' all entities which it retrieves from database (even the list of entities obtained by queries) during single transaction (in the very basic case).
When you make some method #Transactional, by default Hibernate session is flushed when such method is finished. session.flush() is called under the hood.
Once session gets flushed, Hibernate pushes all changes made to these managed entities back into the database.
That is why your changes got to the database, once method was finished, without any additional calls.
To dig deeper into the topic, you can read more about Hibernate managed entities , session flush mode, repository.save(), repository.saveAndFlush() in Spring Data.

Detach entity within entity from persistence context in Hibernate

Hibernate persists modified entities at the of transactional methods, I can avoid by using session#evict(entity).
If I detach it from the persistence context, the entities whithin it will also be detached?
For instance, I have this classes:
#Entity
public class User extends BaseEntity{
#Column(name = "email")
private String email;
#OneToMany(fetch = FetchType.LAZY, mappedBy = "user")
private List<Address> addresses;
// getters and setters
}
#Entity
public class Address extends BaseEntity{
#Column(name = "email")
private String email;
#ManyToOne(fetch = FetchType.LAZY)
#JoinColumn(name = "USER_ID")
private User user;
// getters and setters
}
If I detach a user object, but change the address object in it, will the address be persisted at the end of transaction? Like this:
User user = userDAO.getById(id);
session.evict(user);
Address address = user.getAddresses().get(0);
address.setNumber(number);
addressDAO.saveOrUpdate(address); //will this work?

Entities that are updated or deleted using a EntityManager.createQuery() are not loaded into the Persistence Context, this only happens for select queries, and when you use find()or merge().
After you do an update or delete query your persistence context may actually be out-of-sync with the database, because the query doesn't update the entities which has already been loaded into the persistence context (you need to call refresh() to see the changes).
If you load a number of user (into the persistence context), and later doUpdate User set status='active' where id IN (:ids), then you have not modified any of the users in the persistence context, you have only modified the database. To modify a user, you must modify the actually managed Entity by calling `aUser.setStatus('active'), when the transaction commits, JPA will check all managed entities against a copy created when it was loaded, and if anything has changed it will do an Update.
If you are loading 5000 objects into the Persistence it may take some time for JPA to run though the entity graph, and detect the changes when the transaction commits. If you didn't modify anything, and would like to speed up the change-detection, there are two ways to do this. Load your entities using a read-only query, this tells JPA that it does not need to keep a copy of the loaded entity. The other option is to call EntityManager.clear() to throw away all managed entities. However, if you are interested in performance, the best solution is probably to avoid loading the entities into the persistence context. As I understand you problem, you need to do a Update User set ... where id IN (:ids)and for that you only need the user's id so you don't need to load the user, you just need the ids, and therefore you can do List<Long> ids = em.createQuery("select u.id from User u where ...", Long.class).getResultList();
Hope this clarifies things for you :)
EDIT: this is written from a JPA perspective, but for hibernate EntityManager just forwards directly to SessionImpl, so the behavior is exactly as described, except for find() being called get()in native Hibernate.

Since JPA 2.0
given an EntityManager you can call detach with the entity you want to be detached as parameter
void detach(Object entity)
more here
if you use injection then you can inject an EntityManger in the service where you want to detach the required entity.

Can't delete from two tables with a relation in an #Transaction

I have been using Spring 4's UserDetailsManager to create users, the schema is the one suggested by their docs for USERS and AUTHORITIES tables.
I have also been using the Spring Data #Repository annotated interfaces to manage data in a separate REGISTRATIONS table which is defined to have a relation on the username field in the USERS table.
The problem I've been facing is that when I wish to delete a user, I first delete the record from the REGISTRATIONS table using the injected Spring Data repository, followed by a call to deleteUser() using the UserDetailsManager. (This is simply two consecutive calls in an #Transactional method in an #Service annotated class).
For example
registrationsRepository.delete(uuid);
userDetailsManager.deleteUser(registration.getUsername());
However, the deletion of the user fails as the record in the REGISTRATIONS table (1st line) has not been deleted. Subsequently I get an exception (2nd line) complaining about not being able to delete the user as there are foreign key constrains in the REGISTRATIONS table preventing it from being deleted.
If these updates happen in the same transaction, why does this fail?
EDIT:
#Repository
public interface RegistrationsRepository extends CrudRepository<Registration, UUID>
{
// No EntityManager injected - uses Spring Data method queries
// No additional methods defined
}
Registrations table defined as follows:
CREATE TABLE Registrations (
username varchar(64) NOT NULL REFERENCES Users (username),
uuid UUID NOT NULL PRIMARY KEY
);

So, as I understand it, Spring's UserDetailsManager uses JDBC calls to delete the 'users' and 'authorities' from the respective tables.
My 'registrations' entities were being managed by an EntityManager which had no defined relationship (at the ORM level) to the 'user' records. This relationship was specified purely at the DB level.
The EntityManager would mark the 'registration' entity to be deleted, while the UserDetailsManager would actually delete the 'user', which happens before the EntityManager has been flushed at the end of the transaction. This fails as the 'registration' entity hasn't yet been deleted, the transaction is still not complete, but the JDBC calls had already attempted to delete the 'user's and 'authorities'.
To fix this I did the following.
class DefaultService implements MyService {
private final EntityManagerFactory emf;
// Inject RegistrationRepository and UserDetailsManager...
#Inject
public DefaultService(EntityManagerFactory emf, ...) {
// ...
this.emf = emf;
}
#Override
#Transactional
public void serviceMethod(UUID uuid, String username) {
registrationsRepository.delete(uuid);
// Flush the entity manager to remove this record from the DB first.
EntityManagerHolder entityManagerHolder = (EntityManagerHolder) TransactionSynchronizationManager.getResource(emf);
entityManagerHolder.getEntityManager().flush();
// These will be JDBC calls, 'users' are not managed entities
userDetailsManager.deleteUser(username);
}
}
I obtained the EntityManager in this way to ensure I get the correct one bound to this thread for this transaction. If this is overkill or there is a better way of doing this, please comment!
Hope that helps someone. And is correct!

One DAO per entity - how to handle references?

I am writing an application that has typical two entities: User and UserGroup. The latter may contain one or more instances of the former. I have following (more/less) mapping for that:
User:
public class User {
#Id
#GeneratedValue
private long id;
#ManyToOne(cascade = {CascadeType.MERGE})
#JoinColumn(name="GROUP_ID")
private UserGroup group;
public UserGroup getGroup() {
return group;
}
public void setGroup(UserGroup group) {
this.group = group;
}
}
User group:
public class UserGroup {
#Id
#GeneratedValue
private long id;
#OneToMany(mappedBy="group", cascade = {CascadeType.REMOVE}, targetEntity = User.class)
private Set<User> users;
public void setUsers(Set<User> users) {
this.users = users;
}
}
Now I have a separate DAO class for each of these entities (UserDao and UserGroupDao). All my DAOs have EntityManager injected using #PersistenceContext annotation, like this:
#Transactional
public class SomeDao<T> {
private Class<T> persistentClass;
#PersistenceContext
private EntityManager em;
public T findById(long id) {
return em.find(persistentClass, id);
}
public void save(T entity) {
em.persist(entity);
}
}
With this layout I want to create a new user and assign it to existing user group. I do it like this:
UserGroup ug = userGroupDao.findById(1);
User u = new User();
u.setName("john");
u.setGroup(ug);
userDao.save(u);
Unfortunately I get following exception:
object references an unsaved transient instance - save the transient
instance before flushing: x.y.z.model.User.group ->
x.y.z.model.UserGroup
I investigated it and I think it happens becasue each DAO instance has different entityManager assigned (I checked that - the references in each DAO to entity manager are different) and for user entityManager does not manager the passed UserGroup instance.
I've tried to merge the user group assigned to user into UserDAO's entity manager. There are two problems with that:
It still doesn't work - the entity manager wants to overwrite the existing UserGroup and it gets exception (obviously)
even if it worked I would end up writing merge code for each related entity
Described case works when both find and persist are made using the same entity manager. This points to a question(s):
Is my design broken? I think it is pretty similar to recommended in this answer. Should there be single EntityManager for all DAOs (the web claims otherwise)?
Or should the group assignment be done inside the DAO? in this case I would end up writing a lot of code in the DAOs
Should I get rid of DAOs? If yes, how to handle data access nicely?
any other solution?
I am using Spring as container and Hibernate as JPA implementation.

Different instances of EntityManager are normal in Spring. It creates proxies that dynamically use the entity manager that is currently in a transaction if one exists. Otherwise, a new one will be created.
The problem is that your transactions are too short. Retrieving your user group executes in a transaction (because the findById method is implicitly #Transactional ). But then the transaction commits and the group is detached. When you save the new user, it will create a new transaction which fails because the user references a detached entity.
The way to solve this (and to do such things in general) is to create a method that does the whole operation in a single transaction. Just create that method in a service class (any Spring-managed component will work) and annotate it with #Transactional as well.

I don't know Spring, but the JPA issue is that you are persisting a User that has a reference to a UserGroup, but JPA thinks the UserGroup is transient.
transient is one of the life-cycle states a JPA entity can be in. It means it's just created with the new operator, but has not been persisted yet (does not have a persistent identity yet).
Since you obtain your UserGroup instance via a DAO, it seems like something is wrong there. Your instance should not be transient, but detached. Can you print the Id of the UserGroup instance just after your received it from the DAO? And perhaps also show the findById implementation?
You don't have cascade persist on the group relation, so this normally should just work if the entity was indeed detached. Without a new entity, JPA simply has no way to set the FK correctly, since it would need the Id of the UserGroup instance here but that (seemingly) doesn't exist.
A merge should also not "overwrite" your detached entity. What is the exception that you're getting here?
I only partially agree with the answers being given by the others here about having to put everything in one transaction. Yes, this indeed may be more convenient as the UserGroup instance will still be 'attached', but it should not be -necessary-. JPA is perfectly capable of persisting new entities with references to either other new entities or existing (detached) entities that were obtained in another transaction. See e.g. JPA cascade persist and references to detached entities throws PersistentObjectException. Why?

I am not sure how but I've managed to solve this. The user group I was trying to assign the user to had NULL version field in database (the field annotated with #Version). I figured out it was an issue when I was testing GWT RequestFactory that was using this table. When I set the field to 1 everything started to work (no changes in transaction handling were needed).
If the NULL version field really caused the problem then this would be one of the most misleading exception messages I have ever got.

How to better avoid the LazyInitializationException?

Currently I have a child entity that has a #ManyToOne association to it's parent entity. Previous developers have set this field as lazy="false" to get the parent whenever needed when the session is closed too, however I decided it should be lazy="true" as it's not always used but when doing so I ran into LazyInitializationException because the session is closed and the child is detached from the session when it tries to get the parent.
I was wondering if it's right to move some more logic of the run method as seen bellow to the service class which interacts with DAOs thus I could avoid the exception because currently the service classes are like plain classes which have the needed DAOs injected and they just call the DAO method and returns the result.
Should I put like more methods in the service class which interact with the entities, which would get the user and check everything for log in action, get parent if needed and then just return the log in result to run method..
public class Login extends Runnable {
private UserService userService;
...
public void run() {
...
User user = userSerivce.getById(id);
Account account = user.getAccount(); //LazyInitializationException
...
if (account.isLocked()) {
...
}
...
userService.save(user);
//Send some message to the user..
}
}
public class UserServiceImpl implements UserService {
private UserDAO userDAO;
...
public User getById(long id) {
return userDAO.getById(id);
}
public void save(User user) {
userDAO.save(user);
}
}
public UserDAOImpl implements UserDAO {
private SessionFactory factory;
...
public User getById(long id) {
return (User) factory.getCurrentSession().load(User.class, id);
}
public void save(User user) {
factory.getCurrentSession().saveOrUpdate(user);
}
}
I use Spring's <tx:advice> to handle the closing and other transaction related stuff.

I prefer to have all of my entity relationships as lazy since I don't know if and when I'll need those external entities. This way I can avoid unnecessary joins when I don't need the additional entities. If I do end up needing the entity I create a named query and eager fetch the entity or collection. Here's an example.
I do agree though that you should be sending a DTO instead of the entity back to your calling front end application. Hibernate entities are full of proxies and it would be inefficient to send them back. I'm not really sure if you are sending these objects to a jsp/velocity/etc file or to an external application but I would recommend using a DTO if you are sending back JSON or something similar to the calling application. Here's another question that deals with DTO's click here that discusses 2 frameworks for easy conversion.

Create DTOs, don't send JPA Entities over the net.
When you create the DTOs, you will have to access the required properties, what will trigger to load them.