You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@struts.apache.org by Fabiano Franz <co...@fabianofranz.com> on 2008/03/10 22:37:27 UTC
RE: ModelDriven CRUD validation failure still causes JPA update -
RESOLVED
I had the same issue regarding Struts 2 validations and Hibernate/JPA flush.
My solution:
Write an XWork Interceptor that is placed right after the validation
interceptor on your stack. This interceptor checks the actionErrors and
fieldErrors and, if any of them is not empty, performs a Hibernate/JPA
session clear.
Best regards,
Fabiano Franz
http://fabianofranz.com http://fabianofranz.com
http://literar.org http://literar.org
http://pribi.com.br http://pribi.com.br
cilquirm wrote:
>
> You can throw an exception , which you can specify in your
>
> @Transactional( rollbackFor = )
>
> to have it rollback.
>
>
>
> jon_french wrote:
>>
>> Yes. But I am using Spring managed transactions that in my understanding
>> are outside of the struts Interceptor stack.
>>
>> My DAO's are annotated with the
>> org.springframework.transaction.annotation.Transactional annotation and
>> thus have their transactions managed as detailed here:
>>
>> http://static.springframework.org/spring/docs/2.0.x/reference/transaction.html
>>
>> I'm not an expert (I've only devoted a bit of time to studying the above
>> link), but it is my understanding that Spring wraps my DAO methods with
>> Aspects which control Transaction management (opening/closing).
>>
>> best,
>>
>> Jon French
>> Programmer
>> ASRC Management Services
>> ECOS Development Team
>> jon_french@fws.gov
>> 970-226-9290
>>
>> Fort Collins Science Center
>> US Geological Survey
>> 2150 Centre Ave, Building C
>> Fort Collins, CO 80526-8116
>>
>>
>>
>> "Al Sutton" <al...@alsutton.com>
>> 10/02/2007 12:14 AM
>> Please respond to
>> "Struts Users Mailing List" <us...@struts.apache.org>
>>
>>
>> To
>> "'Struts Users Mailing List'" <us...@struts.apache.org>
>> cc
>>
>> Subject
>> RE: ModelDriven CRUD validation failure still causes JPA update -
>> RESOLVED
>>
>>
>>
>>
>>
>>
>> Just a thought, are you actually using transactions?
>>
>> If so why not modify the interceptor to only commit if a SUCCESS is
>> returned
>> or perform a rollback if ERROR is returned from the action invocation.
>>
>> Al.
>>
>> -----Original Message-----
>> From: Jon_French@fws.gov [mailto:Jon_French@fws.gov]
>> Sent: 02 October 2007 04:04
>> To: Struts Users Mailing List
>> Subject: Re: ModelDriven CRUD validation failure still causes JPA update
>> -
>> RESOLVED
>>
>>
>> OK: I've fixed the problem.
>>
>> I'm not sure why this was the case, but here is what was causing the
>> problem:
>>
>> In my ModelDriven action, I had a method like this:
>>
>> public Collection<ProjectType> getAllProjectTypes(){
>> return this.projectTypeDao.getAll();
>> }
>>
>> Notice that instead of returning a simple instance reference, this method
>> actually returned the result of a JPA query (via the DAO method call).
>>
>> This method was used by a struts 2 iterator tag to populate a select list
>> on the form and was thus called when my "input" JSP rendered after an
>> invalid request.
>>
>> I noticed that in the stack trace of my Oracle constraint violation, it
>> was actually this query call that was triggering the Session.flush() call
>> that was inappropriately saving the invalid entity state to the database.
>> By "pre-loading" the collection in the prepare() method like so:
>>
>> public void prepare() throws Exception {
>> ....
>> this.allProjectTypes = this.projectTypeDao.getAll();
>> }
>>
>> public Collection<ProjectType> getAllProjectTypes(){
>> return this.allProjectTypes;
>> }
>>
>> ... the problematic flush() goes away.
>>
>> Beats me why this matters. I'm sure a JPA guru could explain something
>> about the Transaction or EntityManager instance being different in the
>> two
>>
>> cases, but I don't understand it yet.
>>
>> Jon French
>> Programmer
>> ASRC Management Services
>> ECOS Development Team
>> jon_french@fws.gov
>> 970-226-9290
>>
>> Fort Collins Science Center
>> US Geological Survey
>> 2150 Centre Ave, Building C
>> Fort Collins, CO 80526-8116
>>
>>
>>
>> Jon_French@fws.gov
>> 10/01/2007 08:29 PM
>> Please respond to
>> "Struts Users Mailing List" <us...@struts.apache.org>
>>
>>
>> To
>> "Struts Users Mailing List" <us...@struts.apache.org>
>> cc
>>
>> Subject
>> Re: ModelDriven CRUD validation failure still causes JPA update
>>
>>
>>
>>
>>
>>
>> Unfortunately, it appears that xworks validation works not on the
>> ServletRequest parameters, but on the properties already set on the
>> Action
>>
>>
>> - or in my case the model bean. So moving the interceptor up the stack
>> would just break validation.
>>
>> From the com.opensymphony.xwork2.validator.ValidationInterceptor javadoc:
>>
>> * This interceptor runs the action through the standard validation
>> framework, which in turn checks the action against
>> * any validation rules (found in files such as
>> ActionClass-validation.xml) and adds field-level and action-level
>> * error messages (provided that the action implements {@link
>> com.opensymphony.xwork2.ValidationAware}). This interceptor
>> * is often one of the last (or second to last) interceptors applied in a
>> stack, as it assumes that all values have
>> * already been set on the action.
>>
>> Thanks,
>>
>> Jon French
>> Programmer
>> ASRC Management Services
>> ECOS Development Team
>> jon_french@fws.gov
>> 970-226-9290
>>
>> Fort Collins Science Center
>> US Geological Survey
>> 2150 Centre Ave, Building C
>> Fort Collins, CO 80526-8116
>>
>>
>>
>> Dave Newton <ne...@yahoo.com>
>> 10/01/2007 04:42 PM
>> Please respond to
>> "Struts Users Mailing List" <us...@struts.apache.org>
>>
>>
>> To
>> Struts Users Mailing List <us...@struts.apache.org>
>> cc
>>
>> Subject
>> Re: ModelDriven CRUD validation failure still causes JPA update
>>
>>
>>
>>
>>
>>
>> --- Jon_French@fws.gov wrote:
>>> That's an interesting idea Dave. I'm using the paramsPrepareStack.
>>> It'll take some investigation to
>>
>>> see if that would fix the issue.
>>
>> Shouldn't take much; it might be as simple as adding a
>> validate/defaultWorkFlow up towards the top (although I might try just
>> adding new ones rather than removing the existing ones).
>>
>>> Fort Collins Science Center
>>> US Geological Survey
>>> 2150 Centre Ave, Building C
>>
>> I used to live up Poudre River Canyon (Poudre Park); I
>> sure miss the climbing out there :(
>>
>> d.
>>
>>
>> ---------------------------------------------------------------------
>> 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
>>
>>
>>
>>
>
>
--
View this message in context: http://www.nabble.com/ModelDriven-CRUD-validation-failure-still-causes-JPA-update-tp12987242p15958581.html
Sent from the Struts - User mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
RE: ModelDriven CRUD validation failure still causes JPA update -
RESOLVED
Posted by "Tobias M." <to...@bigfoot.de>.
Hi Fabiano,
first of all thank you for your valuable hint. I established an interceptor
CommitAwareInterceptor at the top of the interceptor stack. This interceptor
is tagging the JPA transaction for RollbackOnly in case of
a.) the action is not implementing CommitAware
b.) the action is implementing CommitAware and the action's
implementation of isCommitable() is returning false.
These checks are performed at the latest step of of the request processing.
This implies that the view is rendered using the old model values i.e. the
old and maybe invalid model state. Every lazy loading is still working at
rendering time.
The only thing the OSIV-Filter has to do is to evaluate the transactions
RollbackOnly-Flag and commit accordingly.
And voila, everything is working fine. Perfect control over the transaction,
no invalid values on the database and no unwanted commits regarding to a.)
Once again, thanks for your hint,
Tobias
Fabiano Franz wrote:
>
> I had the same issue regarding Struts 2 validations and Hibernate/JPA
> flush. My solution:
>
> Write an XWork Interceptor that is placed right after the validation
> interceptor on your stack. This interceptor checks the actionErrors and
> fieldErrors and, if any of them is not empty, performs a Hibernate/JPA
> session clear.
>
> Best regards,
>
> Fabiano Franz
> http://fabianofranz.com
> http://literar.org
> http://pribi.com.br
>
>
--
View this message in context: http://www.nabble.com/ModelDriven-CRUD-validation-failure-still-causes-JPA-update-tp12987242p21062748.html
Sent from the Struts - User mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org