[
https://issues.apache.org/jira/browse/LABS-165?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14031843#comment-14031843
]
jan iversen commented on LABS-165:
----------------------------------
Is this still an issue, if not please close it (or let me close it)
> 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
> Affects Versions: Current
> Reporter: Simone Gianni
> Assignee: Simone Gianni
> Fix For: Future
>
>
> 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 was sent by Atlassian JIRA
(v6.2#6252)
---------------------------------------------------------------------
To unsubscribe, e-mail: labs-unsubscr...@labs.apache.org
For additional commands, e-mail: labs-h...@labs.apache.org
