DATABASE-WEB : transactions should be more careful
--------------------------------------------------
Key: LABS-165
URL: https://issues.apache.org/jira/browse/LABS-165
Project: Labs
Issue Type: Improvement
Components: Magma
Reporter: Simone Gianni
Assignee: Simone Gianni
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.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
