Have you tried to put the transational annotation in the class declaration?
Maurizio Cucchiara Il giorno 09/mar/2011 21.38, "CRANFORD, CHRIS" <chris.cranf...@setech.com> ha scritto: > I still think this is related to my @Transactional annotation maybe. > >> -----Original Message----- >> From: Dave Newton [mailto:davelnew...@gmail.com] >> Sent: Wednesday, March 09, 2011 2:16 PM >> To: Struts Users Mailing List >> Subject: Re: Re : Re : ModelDriven & Hibernate Entities >> >> Another reason OSiV filters can be tricky. >> >> Dave >> >> On Wed, Mar 9, 2011 at 2:04 PM, CRANFORD, CHRIS >> <chris.cranf...@setech.com> wrote: >> > Francois - >> > >> > I use the standard paramsPrepareParamsStack interceptor from Struts. >> > >> > All I have done on my end is wrap this interceptor stack with a few >> application specific interceptors that control things such as >> authentication required, auditing, and logging. I stepped upon my >> issue one day when I had returned from lunch and my session had timed >> out. I hit the SAVE button on a form and it redirected me to our login >> page. >> > >> > But prior to logging back in; I checked the database and noticed that >> the record was in fact persisted with the changes from the form. All I >> can gather is the following: >> > >> > 1. Request comes in for Struts >> > 2. Hibernate Session opened via OSIV >> > 3. Model is loaded from DB via prepare() >> > 4. Struts copies parameters into the model >> > 5. Validation/Interceptors fire >> > 6. Authentication Interceptor detects timed out session, returns >> LOGIN >> > 7. User presented with login page >> > 8. OSIV filter closes, changes from #4 persisted. >> > >> > I then created a simple test action where I load a persist entity >> from the DB in a ModelDriven action, I call the action passing >> parameters that are properties on the entity. Then the execute() >> method does nothing more than return SUCCESS which maps to my >> /pages/done.jsp. The changes are committed. >> > >> > I'd prefer that changes aren't committed unless I explicitly call to >> do so on the EntityManager; however I understand Hibernate/JPA's >> reasons behind why it works the way it does. >> > >> > >> > >> >> -----Original Message----- >> >> From: François Rouxel [mailto:rouxe...@yahoo.com] >> >> Sent: Wednesday, March 09, 2011 12:24 PM >> >> To: Struts Users Mailing List >> >> Subject: Re : Re : ModelDriven & Hibernate Entities >> >> >> >> Hi Chris, >> >> first, >> >> you might have another pb, because struts2 does not change your >> model >> >> if a >> >> validation failed. In may case, the model is not changed so not >> >> persisted. Do u >> >> use validation and workflow interceptor ? >> >> second, >> >> you are right about MVC pattern, but, just be aware that when you >> use >> >> OSIV >> >> pattern, hibernate call backend service when loading data...:-)) so >> >> your JSP is >> >> not just a view in that case.... >> >> >> >> >> >> I wrote my first mail thinking you wanna rollback after an exception >> >> occured. >> >> maybe it's gonna help others. >> >> >> >> fr/ >> >> >> >> >> >> ____________________________________________ >> >> ____________________________________________ >> >> >> >> >> >> >> >> ----- Message d'origine ---- >> >> De : "CRANFORD, CHRIS" <chris.cranf...@setech.com> >> >> À : Struts Users Mailing List <user@struts.apache.org> >> >> Envoyé le : Mer 9 mars 2011, 13h 09min 33s >> >> Objet : RE: Re : ModelDriven & Hibernate Entities >> >> >> >> Francois - >> >> >> >> While that may work for you, I wouldn't place anything Hibernate or >> >> persistence >> >> related in my JSP pages at all. In my mind, this breaks the entire >> >> reasoning >> >> behind MVC and the view simply there to render data. If the view is >> >> doing >> >> anything beyond that, I have a design problem, but again that's my >> >> opinion. >> >> >> >> But what about when you use the INPUT result code in your execute() >> >> method. >> >> >> >> If I return the user to the INPUT method because maybe I'm not using >> >> the Struts >> >> validation framework and doing it myself in my execute() method or I >> >> have some >> >> complex conditions I must check for before I save the data. In this >> >> case, by >> >> returning INPUT and setting some action field or error messages to >> be >> >> shown to >> >> the user, the error exception handler isn't fired, thus your >> rollback >> >> isn't >> >> fired either; leaving your entity persisted with likely dirty data. >> >> >> >> > -----Original Message----- >> >> > From: François Rouxel [mailto:rouxe...@yahoo.com] >> >> > Sent: Wednesday, March 09, 2011 11:43 AM >> >> > To: Struts Users Mailing List >> >> > Subject: Re : ModelDriven & Hibernate Entities >> >> > >> >> > same issue >> >> > this how I fixed it : (the main idea is to redirect to a jsp if >> an >> >> > exception >> >> > occured, and the jsp rollback) >> >> > >> >> > create an error page error.jsp >> >> > <%@page import="com.rdvcentral.util.persistance.HibernateUtil"%> >> >> > <%@ page contentType="text/html;charset=UTF-8" language="java" %> >> >> > <%@ taglib prefix="s" uri="/struts-tags" %> >> >> > <%@ taglib prefix="sj" uri="/struts-jquery-tags" %> >> >> > >> >> > >> >> > <%@page import="org.hibernate.Transaction"%> >> >> > <%@page import="org.apache.log4j.Logger"%> >> >> > >> >> > <s:property value="%{logError(exception)}"/> >> >> > <% >> >> > Transaction tx = new >> >> > >> >> >> HibernateUtil().getSessionFactory().getCurrentSession().getTransaction( >> >> > ); >> >> > if (tx != null && tx.isActive()) { >> >> > tx.rollback(); >> >> > } >> >> > %> >> >> > >> >> > In your struts mapping file : >> >> > >> >> > <global-results> >> >> > <result name="unhandledException">/error.jsp</result> >> >> > </result> >> >> > </global-results> >> >> > >> >> > <global-exception-mappings> >> >> > <exception-mapping exception="java.lang.Exception" >> >> > result="unhandledException" /> >> >> > </global-exception-mappings> >> >> > >> >> > hope it will help you >> >> > >> >> > >> >> > ____________________________________________ >> >> > ____________________________________________ >> >> > >> >> > >> >> > >> >> > ----- Message d'origine ---- >> >> > De : "CRANFORD, CHRIS" <chris.cranf...@setech.com> >> >> > À : Struts Users Mailing List <user@struts.apache.org> >> >> > Envoyé le : Mer 9 mars 2011, 12h 34min 32s >> >> > Objet : ModelDriven & Hibernate Entities >> >> > >> >> > I had started down a path of using the ModelDriven interface from >> >> > Struts >> >> > because I find it really helps maintain a class action class >> without >> >> > large numbers of get/set methods for screens that contain a lot of >> >> form >> >> > fields. >> >> > >> >> > However, I am finding at least with how I have attempted to >> approach >> >> > ModelDriven to have several drawbacks. For example, by using the >> >> OSIV >> >> > (Open Session In View) filter, I am finding that when Struts sets >> the >> >> > properties on the entity and afterward if an exception is thrown, >> >> > caught >> >> > and handled and doesn't trigger Hibernate to actually "rollback"; >> the >> >> > changes are persisted which leaves my entity in a dirty >> inconsistent >> >> > state. >> >> > >> >> > How have others solved this by using your entity domain POJOs in >> your >> >> > view? >> >> > >> >> > Do you use them detached from the session so that you explicitly >> have >> >> > to >> >> > merge them to the session to be persisted? If so, how do you deal >> >> with >> >> > multiple lazy loaded collections in your entity? >> >> > >> >> > Or would using DTO objects from my service layer a better >> alternative >> >> > to >> >> > insure that no data is actually persisted to the database that >> >> > shouldn't >> >> > be? >> >> > >> >> > >> >> > ------------------------------------------------------------------ >> --- >> >> > 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 >> >> >> > >> > >> > >> > --------------------------------------------------------------------- >> > 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 >
