Sorry for the late reply.
anonymous wrote : The log message certainly doesn't jump out and bite you!
anonymous wrote : Does it stand out if the queries are not displayed fully?
The output I pasted in this thread is that with DEBUG set for
log4j.logger.org.jbpm . So it is definitely insufficien
Does it stand out if the queries are not displayed fully?
View the original post :
http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4064574#4064574
Reply to the post :
http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4064574
_
anonymous wrote : Bit a pitty it is so easily overlooked if you don't define an
exception handler in your process.
The log message certainly doesn't jump out and bite you!
Do you perhaps want to JIRA it?
-Ed Staub
View the original post :
http://www.jboss.com/index.html?module=bb&op=viewtopic
Ok, I found it. A stupid mistake for a change. I should have seen the
| select exceptionh0_.PROCESSDEFINITION_ as PROCESSD5_1_, except
| ionh0_.ID_ as ID1_1_, exceptionh0_.GRAPHELEMENTINDEX_ as GRAPHELE6_1_,
exceptionh0_.ID_ as ID1_7_0_,
| exceptionh0_.EXCEPTIONCLASSNAME_ as EXCEPTIO2_7_0
There is only one thread, that's just the next loop in the test. The
setRollBackOnly() idea is worth checking out, I'll do that. Thanks
Johan
View the original post :
http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4064054#4064054
Reply to the post :
http://www.jboss.com/index.html
I don't know anything about the Sybase driver.
But I think it's very possible that setRollbackOnly() was set much earlier, and
the log message is only reflecting it much later at commit time.
The "4,033ms executing PreparedStatement: SELECT..." log at the end looks
strange in the context of clo
Thanks for the reaction guys!
The queries contain some sensitive/personal data and I just don't want my head
chopped off by my boss :-P
Well I can post an edited (and somewhat shorter version of the output). It
contains JBPM log info but also the queries, I don't think it is confusing. The
"s
"estaub" wrote :
| If you're wondering how to keep an application rollback from rolling back
JBPM's persistence - me too! My current theory is to wrap all application work
under a command-pattern SLSB that's set to REQUIRES_NEW. If you come up with
anything better, please write it up!
Does
What's the question? Is it
"Where is the rollback?"
If so, all I can offer is the usual advice - log everything.
If that doesn't lead anywhere, you could start inserting getRollbackOnly()
calls to narrow it down.
If you're wondering how to keep an application rollback from rolling back
JBP
Jsut out of curiosity... why can't you cut and paste the logging here?
The other info (to me) is not enough, I'm no persistency expert... sorry
View the original post :
http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4063991#4063991
Reply to the post :
http://www.jboss.com/index.html
10 matches
Mail list logo
