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
