struts-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Maurizio Cucchiara <maurizio.cucchi...@gmail.com>
Subject Re: RE: Re : Re : ModelDriven & Hibernate Entities
Date Wed, 09 Mar 2011 22:20:14 GMT
Have you tried to put the transational annotation in the class declaration?

Maurizio Cucchiara

Il giorno 09/mar/2011 21.38, "CRANFORD, CHRIS" <Chris.Cranford@setech.com>
ha scritto:
> I still think this is related to my @Transactional annotation maybe.
>
>> -----Original Message-----
>> From: Dave Newton [mailto:davelnewton@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.Cranford@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:rouxelec@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.Cranford@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:rouxelec@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.Cranford@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-unsubscribe@struts.apache.org
>> >> > For additional commands, e-mail: user-help@struts.apache.org
>> >> >
>> >> >
>> >> >
>> >> >
>> >> > ------------------------------------------------------------------
>> ---
>> >> > To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
>> >> > For additional commands, e-mail: user-help@struts.apache.org
>> >> >
>> >>
>> >>
>> >>
>> >> --------------------------------------------------------------------
>> -
>> >> To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
>> >> For additional commands, e-mail: user-help@struts.apache.org
>> >>
>> >>
>> >>
>> >>
>> >> --------------------------------------------------------------------
>> -
>> >> To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
>> >> For additional commands, e-mail: user-help@struts.apache.org
>> >>
>> >
>> >
>> >
>> > ---------------------------------------------------------------------
>> > To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
>> > For additional commands, e-mail: user-help@struts.apache.org
>> >
>> >
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
>> For additional commands, e-mail: user-help@struts.apache.org
>>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
> For additional commands, e-mail: user-help@struts.apache.org
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message