Burton - I continued to dig around the code yesterday despite my frustration with the situation in not being able to find a way to make all this work. It just didn't seem right that this wouldn't work IMO. After turning on Spring's DEBUG and watching the transaction management statements happen, I stumbled across what I feel was the culprit.
We have a number of interceptors in our code base that perform various initialization activities before the destination action is ever invoked along with some which do pre-result and post-result activities. After looking at my interceptor stack, one of them was doing a merge action to write some breadcrumb data to an audit table during a pre-result listener. So the series of events were: 1. Model Driven action called 2. Model loaded from database (attached entity) 3. Parameters were loaded into model (entity now modified) 4. Validation occurred 5. Execute method fired (simply returns SUCCESS) Well after the action returns SUCCESS and the PreResultListener gets executed that does the EntityManager MERGE call. This not only persisted the audit record to the database but it also commits any changes pending, which would include the modified entity in #3 above. >From what I have gathered with OSIV, the transaction is opened and you can >query the database and make changes to your entities but once a call is made >to the entity manager to remove/persist/merge an entity, all bets are off; any >pending changes will be flushed. So what I decided to test was adding one more interceptor to the stack that clears the entity manager after the action's execution; effectively forcing a rollback for any entities which were not explicitly persisted. Then the audit interceptor was changed from a pre-result to a post-result action and takes place right after the clearing of my entity manager. Now the audit service doesn't persist any pending changes from my action environment. Anyone see any flaws or issues with this? So long as my action is making a single call in my execute() method to my business logic with my model, then I should be ok? > -----Original Message----- > From: Burton Rhodes [mailto:burtonrho...@gmail.com] > Sent: Thursday, March 10, 2011 7:49 PM > To: Struts Users Mailing List > Subject: Re: RE: Re : Re : ModelDriven & Hibernate Entities > > I have never run into this issue while using OiSV, but couldn't it be > easily solved by not referencing any related entity or collections > directly from the model you are modifying in your action? In other > words, the object that is in your model (e.g Customer) would be in > getModel() and in the form for the JSP, but all other data dispayed on > the page would be reference by a "clean" version of Customer. I'm > sure it can't be that simple, but trying to help. > > On Thu, Mar 10, 2011 at 7:39 PM, Burton Rhodes <burtonrho...@gmail.com> > wrote: > > Here is an old thread talking of this same issue. It appears some > > suggestions are given, but still an issue. Dave was *marginally* > > following this thread as well ;-) > > > > http://www.coderanch.com/t/58423/Struts/Struts-Model-Driven- > fundamentally-flawed > > > > > > On Thu, Mar 10, 2011 at 11:55 AM, CRANFORD, CHRIS > > <chris.cranf...@setech.com> wrote: > >> Dave et el - > >> > >> I can only conclude that either something is severely lost in my > >> understanding of a Struts2 ModelDriven action coupled with Spring3 > and > >> Hibernate/JPA. I have tried numerous configuration changes, > >> annotations, etc and nothing has appeared to avoid allowing dirty > data > >> to make it to the database and I just cannot continue with this > risk; it > >> just jeopardizes integrity. > >> > >> So unless someone can shed some light on my implementation, showing > what > >> could be flawed; then I need to go down a different path. > >> > >> I like the notion that the ModelDriven does a lot of the grunt work > for > >> me with respect of populating my entity based on form properties and > >> keeps my action class very clean and free of form bloat; however I > feel > >> it puts some risks on the table which I could easily avoid by not > >> allowing the framework to modify my persistent entity and force me > to > >> manage the copy/update of the entity accordingly when applicable. > >> > >>> -----Original Message----- > >>> From: Dave Newton [mailto:davelnew...@gmail.com] > >>> Sent: Thursday, March 10, 2011 10:40 AM > >>> To: CRANFORD, CHRIS > >>> Cc: Struts Users Mailing List; Maurizio Cucchiara > >>> Subject: Re: RE: Re : Re : ModelDriven & Hibernate Entities > >>> > >>> On Thu, Mar 10, 2011 at 11:38 AM, CRANFORD, CHRIS wrote: > >>> > Yes the plugin is in the app's lib directory. > >>> > >>> Just FYI, that sets the object factory to "spring", so Spring is > >>> instantiating your actions. > >>> > >>> (At least it used to.) > >>> > >>> Dave > >> > >> > >> > >> -------------------------------------------------------------------- > - > >> To unsubscribe, e-mail: user-unsubscr...@struts.apache.org > >> For additional commands, e-mail: user-h...@struts.apache.org > >> > >> > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: user-unsubscr...@struts.apache.org > For additional commands, e-mail: user-h...@struts.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: user-unsubscr...@struts.apache.org For additional commands, e-mail: user-h...@struts.apache.org
