Question

I am writing a JSF 2.0 form to edit a JPA @Entity object. I have a backing bean that has a get method for the Entity, which it fetches from the EntityManager. So far so good.

The question is does the Entity object that is being edited by the user get accessed by other parts of the application? In other words if someone else calls up that record, do they see the field changes before I merge the record back into the data base via the EntityManager? Or do they get a different instance.

The reason this is important is that the user can enter all sorts of bad data. The validation phase done by the backing bean will not call merge() all the errors are cleared, but what about before then?

If this is a common instance, how do I avoid this problem?

Answer 1

The question is does the Entity object that is being edited by the user get accessed by other parts of the application? In other words if someone else calls up that record, do they see the field changes before I merge the record back into the data base via the EntityManager? Or do they get a different instance.

The entity instance used by JSF will be a detached entity instance. It is not one that belongs to the persistence context. Each client/user will also receive it’s own instance of the detached entity.

The reason this is important is that the user can enter all sorts of bad data. The validation phase done by the backing bean will not call merge() all the errors are cleared, but what about before then?

The merging of any invalid data will occur on when you invoke EntityManager.merge to merge the contents of the detached entity with the persistence context. If you never invoked merge, then the modified contents of the Entity will never make it to the persistence context.

If this is a common instance, how do I avoid this problem?

You can always avoid this by validating the state of the entity before merging it with the persistence context. You could employ bean validation in both JSF and JPA, to prevent this scenario, although you will typically do this only in one layer, to prevent redundant checks. However, if you have specified validation groups for your bean validation constraints to distinguish between presentation and persistence constraints, then you ought be employing bean validation in both the layers. Do keep in mind, that once the contents of the bean have been merged successfully with the persistence context, there isn’t a lot you can do to undo this change, except for a transaction rollback, or a refresh/clear of the persistence context.