Major Description
Currently, in a web environment, all the web page lives in a single transaction. This is somewhat dangerous. First of all, a small error in a subcomponent could make all the page fail, also on the database, but this is not a big concern because it is what many other frameworks out there does.
The biggest problem is another one : there is no way to avoid committing partial stuff. For example, I may have a form that modifies a bean. If validation fails, there is a small (thanks to the handler) but yet possible situation where the bean is partially modified. In this case, by default, JPA will persist changes if the transaction is flushed and committed, also if Database.save() is not explicitly called.
Also, the user could naively modify the bean thinking that, since Database.save is not called, the data on the database will stay there and not be modified by anyone.
There could be a number of approaches to solve these problems :
- The JPA implementation should be configured to flush to the database only stuff which has been explicitly required thru a Database.save operation ... this was possible in Hibernate, no idea if there is a standard way to do it in JPA.
- The Database implementation should do this on behalf of JPA. As a first step to commit the transaction only if Database.save has been called at least once. Second refreshing bean state for those beans not interested directly in a save operation before committing.
This second approach is quite hard to achieve : first of all we need access to all beans returned by JPA and currently in the entity manager. Intercepting the query methods and building the index by ourselves is not simple, cause the returned collection will probably be lazy, so wrapping of this collection should take place. At that point, before committing, all elements in the "databsse objects pool" which does not have a corresponding "save" statement should be refreshed. Again, this could be a problem, cause changes could have been performed on a sub-bean retrieved by a query, and then saved saving the parent, as in the following snippet :
Address address = db.load(Address.class, 150);
address.setZipCode("00131");
Person p = address.getPerson();
db.save(p);
This is perfectly legal JPA code (if the relation person->address propagates updates), that will persist the person to persiste changes in address. In this case, the address should not be rolled back.