[
https://issues.apache.org/jira/browse/LABS-165?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12632017#action_12632017
]
Simone Gianni commented on LABS-165:
------------------------------------
Another simpler approach could be to flush whenever is needed, but to commit
only if a Database.save operation is performed during the transaction lifespan.
In this case, if the user does not call Database.save, nothing will be saved.
This is simple to do, but still leaves the following situation a problem :
for (Person happy : happyPeople) {
try {
p.setHappy(true);
p.addMessage("I'm in happy people");
db.save(p);
} catch (Exception e) {
// This is non fatal, so no handling required
}
}
The user could think "I save only if i managed to set both the happy flag and
the message", while in reality all users where only setHappy succeded but
addMessage throw exception will be saved ad being happy.
> 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]
