 | Mailing List | | Home | | Forum Home | | JBoss - Java Application Server | | Tomcat - JSP/Servlet container | | Struts - A MVC web framework | | iText - An open source PDF Java Library | | JDOM - JDOM XML Parser | | JSP - A mailing list about Java Server Pages specification and reference | | J2EE - A mailing list for Java(tm) 2 Platform, Enterprise Edition | | J2EE Pattern - An interest list for Sun Java Center J2EE Pattern Catalog | | Servlet - A mailing list for discussion about Sun Microsystem's Java Servlet API Technology | |
Struts & Hibernate
|
|
|
| | | -none- | -none- 2007-10-02 - By Al Sutton
Back
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@(protected) [mailto:Jon_French@(protected)]
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@(protected)
970-226-9290
Fort Collins Science Center
US Geological Survey
2150 Centre Ave, Building C
Fort Collins, CO 80526-8116
Jon_French@(protected)
10/01/2007 08:29 PM
Please respond to
"Struts Users Mailing List" <user@(protected)>
To
"Struts Users Mailing List" <user@(protected)>
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.
|
|
|
