|
Home > Archive > WebSphere Application Server > August 2006 > LocalTransaction rolled-back due to setRollbackOnly
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
LocalTransaction rolled-back due to setRollbackOnly
|
|
|
| I switched from defining the database connections in my application to defining them on the WAS server and I'm getting the subject error. The solutions in http://www-1.ibm.com/support/docvie...uid=swg21141640 are not very practical since it involves a
nd extra step of using AAT adding specifications for every servlet. This is an extra, error-prone step and highly undesirable.
We are using Hibernate and Spring to manage the connections so we have no control over that code to fix the problem there. We are also using Eclipse and Tomcat for development so we don't have WSAD to help solve the problem.
Is there any way we can solve this problem?
-- Frank
| |
| Paul Ilechko 2006-08-22, 7:39 pm |
| flawlor@athensgroup.com wrote:
> I switched from defining the database connections in my application
> to defining them on the WAS server and I'm getting the subject error.
> The solutions in
> http://www-1.ibm.com/support/docvie...uid=swg21141640 are not very
> practical since it involves and extra step of using AAT adding
> specifications for every servlet. This is an extra, error-prone step
> and highly undesirable.
I'm pretty sure that you can script this as part of the build, making it
not error prone.
> We are using Hibernate and Spring to manage the connections so we
> have no control over that code to fix the problem there.
Sure you do - it's open source. Join the team and fix it. (Although I'm
skeptical that the bug really is in Spring or Hibernate, as lots of
people do this successfully. It's more likely a problem with your code).
> We are also
> using Eclipse and Tomcat for development so we don't have WSAD to
> help solve the problem.
>
> Is there any way we can solve this problem?
Don't do database access in the web container. Use Stateless Session
EJBs, and have full control over transaction attributes and boundaries.
That's what they are there for.
| |
|
| > flawlor@athensgroup.com wrote:
> in my application
> the subject error.
> http://www-1.ibm.com/support/docview.wss?uid=swg211416
> 40 are not very
> AAT adding
> extra, error-prone step
>
> I'm pretty sure that you can script this as part of
> the build, making it
> not error prone.
Everytime a servlet is added, removed the script needs to change and failure to do so is a nasty deployment error. This kind of thing is very undesirable in a robust deployment process.
>
> connections so we
> there.
>
> Sure you do - it's open source. Join the team and fix
> it. (Although I'm
> skeptical that the bug really is in Spring or
> Hibernate, as lots of
> people do this successfully. It's more likely a
> problem with your code).
>
I've been down the road of modifying open source. This again is a rather unmaintainable and undesirable.
> don't have WSAD to
>
> Don't do database access in the web container. Use
> Stateless Session
> EJBs, and have full control over transaction
> attributes and boundaries.
> That's what they are there for.
No, this is what we are using Hibernate/Spring for.
It manages sessions, connections, transactions, etc transparently.
Adding EJBs would just be fighting it.
Thanks for responding, but these are all very heavyweight solutions for what shouldn't be an issue in the first place and should, at most, be a SINGLE property on the datasource or transaction manager which essentially says "Unhandled action = Commit" (as
the IBM reference I gave indicates).
| |
| Paul Ilechko 2006-08-23, 1:31 am |
| flawlor@athensgroup.com wrote:
[vbcol=seagreen]
>
> No, this is what we are using Hibernate/Spring for. It manages
> sessions, connections, transactions, etc transparently. Adding EJBs
> would just be fighting it.
We'll have to agree to disagree on this. Session EJBs are not a
heavyweight solution, and Spring is an overblown solution to a bunch of
already solved problems, IMO. Not only that, but I really dislike the
whole concept of dependency injection, which tends to lead to poor
design and bleeding of inappropriate knowledge across layers. I'm not
really crazy about any kind of O/R mapping, for that matter, be it
Hibernate, JDO or Entity Bean. The idea that developers can build good
systems without understanding SQL or database structure has been
consistently proven false in my experience. YMMV.
| |
|
| > flawlor@athensgroup.com wrote:
>
>
> Stateless
> transaction attributes and
> It manages
> transparently. Adding EJBs
>
> We'll have to agree to disagree on this. Session EJBs
> are not a
> heavyweight solution, and Spring is an overblown
> solution to a bunch of
> already solved problems, IMO. Not only that, but I
> really dislike the
> whole concept of dependency injection, which tends to
> lead to poor
> design and bleeding of inappropriate knowledge across
> layers. I'm not
> really crazy about any kind of O/R mapping, for that
> matter, be it
> Hibernate, JDO or Entity Bean. The idea that
> developers can build good
> systems without understanding SQL or database
> structure has been
> consistently proven false in my experience. YMMV.
I'm no fan of either Hibernate or Spring, but they are the infrastructure chosen (long ago) for the app. Introducing an alternartive solution into an existing application to solve a minor problem is not a good approach. I just need to make this "minor"
change to WebSphere datasources work.
The merits or demerits of Hibernate/Spring versus Session Beans isn't at issue.
I learned long ago that sticking with one imperfect solution is far better than layering on a competing technology to solve a minor problem. Introducing EJBs at this point is far too heavyweight a solution to what should be a trivial configuration proble
m. Again, "Unhandled action = Commit" in the right spot should be the maximum extent of a solution.
-- Frank
| |
| Randy Schnier 2006-08-23, 1:29 pm |
| The file where the UnresolvedAction=commit setting is stored is
META-INF/ibm-web-ext.xmi in the web module. Unfortunately, I don't have
an example handy to give you the exact syntax, but you could modify one
servlet using AST (as described in the link), look at its
ibm-web-ext.xmi file to see how the setting is specified within that
file, then change your other servlets (outside AST) to update the
UnresolvedAction setting.
Hope this helps.
flawlor@athensgroup.com wrote:
> I switched from defining the database connections in my application to defining them on the WAS server and I'm getting the subject error. The solutions in http://www-1.ibm.com/support/docvie...uid=swg21141640 are not very practical since it involves
and extra step of using AAT adding specifications for every servlet. This is an extra, error-prone step and highly undesirable.
>
> We are using Hibernate and Spring to manage the connections so we have no control over that code to fix the problem there. We are also using Eclipse and Tomcat for development so we don't have WSAD to help solve the problem.
>
> Is there any way we can solve this problem?
>
> -- Frank
| |
|
| Thanks, that was a helpful suggestion.
For anyone who needs to do this here is what I did.
I used a copy of WSAD to generate the extension entries in the file ibm-web-ext.xmi. To do this edit web.xml and click on the servlets tab. Select a servlet. On the bottom right hand side of the page you MIGHT see three dropdowns labeled Boundary, Reso
lver and Unresolved Action (Interestingly, on one WSAD/App I looked at, they were not there???). In the Unresolved Action dropdown select commit.
The ibm-web-ext.xmi file looks something like:
<?xml version="1.0" encoding="UTF-8"?>
<webappext:WebAppExtension xmi:version="2.0" xmlns:xmi="http://www.omg.org/XMI" xmlns:webappext="webappext.xmi" xmi:id="WebAppExtension_1" reloadInterval="3" reloadingEnabled="true" additionalClassPath="" fileServingEnabled="true" directoryBrowsingEnabled
="false" serveServletsByClassnameEnabled="true">
<webApp href="WEB-INF/web.xml#WebApp"/>
<extendedServlets xmi:id="ServletExtension_001">
<extendedServlet href="WEB-INF/web.xml#Servlet_001"/>
<localTransaction xmi:id="LocalTransaction_001" unresolvedAction="Commit"/>
</extendedServlets>
</webappext:WebAppExtension>
In your web.xml file you need to add a corresponding id to you servlet tags, eg.
<Servlet id="Servlet_001">
Do this for each servlet with a different number and make sure there is a corresponding entry in ibm-web-ext.xmi.
Also, in web.xml modify the web-app tag to add an id:
<web-app id="WebApp">
this corresponds to the reference in ibm-web-ext.xmi.
This got rid of most, but not all the exceptions (for example, the login page is still throwing the exception).
IBM should really fix this properly. This commit property is properly a model layer attribute, not a control layer property and should only have to be specified (at most) once. The current IBM "solution" makes this far more complex than it should be and
very unmaintainable.
Thanks,
-- Frank
| |
| Randy Schnier 2006-08-23, 7:31 pm |
| Glad you got this working Frank.
Unfortunately, you're effectively performing the transactional scoping
within your view/controller layer (the servlet), so that's where the
property has to be applied in this case.
If your servlet invoked a stateless session EJB, then the EJB container
would automatically handle this for you. (That is, it would
automatically ensure that the local transaction was either committed or
rolled back prior to returning control to the servlet.)
flawlor@athensgroup.com wrote:
>
> IBM should really fix this properly. This commit property is properly a model layer attribute, not a control layer property and should only have to be specified (at most) once. The current IBM "solution" makes this far more complex than it should be a
nd very unmaintainable.
>
> Thanks,
> -- Frank
|
|
|
|
|