I think your fix sounds logical. My true knowledge of the @Transactional annotation isn't that great although I use it quite a bit (yikes), so this suggestion may be way off base.... but would setting the code inside your pre-result or post-result inteceptor as @Transactional(propagation = Propagation.REQUIRES_NEW) help in any way?
On Fri, Mar 11, 2011 at 9:10 AM, CRANFORD, CHRIS <chris.cranf...@setech.com> wrote: > 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 > > --------------------------------------------------------------------- To unsubscribe, e-mail: user-unsubscr...@struts.apache.org For additional commands, e-mail: user-h...@struts.apache.org
