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
