Hi all,
Although the lock=UPGRADE without the session.flush() solves the problem
in 3.3.0.GA, the same solution in version 3.2.3 does not work.
For our company this is not a problem, we can switch to 3.3.0.GA easily since
we do not run production right now.
I thought this was valuable
Yes, I've seen it. I'll respond later today
View the original post :
http://www.jboss.com/index.html?module=bbop=viewtopicp=4197563#4197563
Reply to the post :
http://www.jboss.com/index.html?module=bbop=postingmode=replyp=4197563
___
jboss-user
To All,
Specifying the lock=UPGRADE on the join node does the trick!!
Even without the call to session.flush() in the join class.
I want to thank all of you for your great support!!!
Hopefully the fix for this bug can be included in the next release.
Thanks again!
Jan
View the
Thanks for reporting back... for me it would not be the solution, but we could
chance the default for oracle to 'upgrade' if de process is parsed. Otoh, maybe
just a 'known-issue' regarding these specific processdefinition cases would be
better. I hate putting db/as/jdk specific code in my
Ronald,
i've send you an email using ron...@jbpm.org. Do you still use that email
address??
View the original post :
http://www.jboss.com/index.html?module=bbop=viewtopicp=4197520#4197520
Reply to the post :
http://www.jboss.com/index.html?module=bbop=postingmode=replyp=4197520
We are having the same problem. Has anyone tried other options like
optimistic-lock=false
on some of the relationships between token and the other tables? The children
relationship looks suspect in that is a child Token gets removed or added, the
version of the parent Token is incremented.
Ronald, thanks for the unit test. I executed it against mysql, postgres and
oracle (the real ones and not just h2 in the different modes to be sure), and
here is what I've found:
+ join name='join' /* the default: leads to StaleObjectStateException
with Oracle and Postgres */
| //+ join
Martin,
can we set the lock attribute in the processdefinition.xml?? Not according to
the documentation imho.
Jan
View the original post :
http://www.jboss.com/index.html?module=bbop=viewtopicp=4197124#4197124
Reply to the post :
@Jan,
Yes, the lock can be on the processdefinition. If it complaints and you have a
reference to the xsd, remove that validating against the xsd does not work
then. (also a jira issue might be created then for the xsd to be updated)
@Martin.. Yes, I'd like to but I get 403's when
@erciped:
No, and I can't (at least not against a real Oracle or PostgreSQL). I agree
that the issue seems to be in that direction. Can you give it a try?
View the original post :
http://www.jboss.com/index.html?module=bbop=viewtopicp=4197226#4197226
Reply to the post :
anonymous wrote : Is raises the question wether jbpm is the right choice for
enterprise software??[/qupte]
|
| A valid one (but it is... I can assure you it is used in big companies in
very important environments), and I already inquired with 'QA' people about the
status of getting access
Ronald,
I will post some new treads about the other oracle related problems soon.
But the main issue there is (as far as I can see) that the oracle
implementation does not auto increment the id fields. Apart from creating a
hibernate-sequence, the jbpm (or hibernate) does not seem to use
To finish up on my tests from yesterday, removing the flush() in the Join
re-introduced the failure on the direct link from fork to join:
| HSQLDB: 3.2.2: OK, 3.2.3: OK, 3.3.0: OK
| Oracle: 3.2.2: FAILED, 3.2.3: OK, 3.3.0: FAILED
| Postgres: 3.2.2: FAILED, 3.2.3: OK, 3.3.0:
Martin,
I did a similar test with 3.3.0 and run it against HSQLDB, H2 and mysql with
and without the flush added. They run fine strange... can you post your
unit test so we are sure we use the same test?
View the original post :
if I only had a unit test... sigh... the lack of a proper test is probably the
reason why the failure was reintroduced in 3.3.0.
I'm pretty convinced this issue only shows on certain dbs, such as Oracle and
Postgres. I can give it another try on MySQL, too (and then write a proper test
;-) )
Martin... I found a similarity Oracle and Postgress use sequences, mysql,
h2 and hsqldb use auto-increment like id's. I've seen that postgress can also
support auto-increment if the int8 is changed to 'serial', see
H2 is cl. it has an oracle and postgress compatible mode If
you use it's own H2 driver, but point to a Oracle dialect and state in the
connect string the mode is oracle, like:
| !-- hibernate dialect --
|
| property
Martin, Just posted the test result before your last response
Jan
View the original post :
http://www.jboss.com/index.html?module=bbop=viewtopicp=4196560#4196560
Reply to the post :
http://www.jboss.com/index.html?module=bbop=postingmode=replyp=4196560
Can you also try to run with debug on org.jbpm.graph.node.Join? I'm curious to
the value of the lockmode. You can also see that in the database on the
definition of the specific join node.
View the original post :
http://www.jboss.com/index.html?module=bbop=viewtopicp=4196571#4196571
Reply
Ronald,
We use transaction level Read-committed as adviced in the documentation.
local-tx-datasource
| jndi-nameJbpmDS/jndi-name
|
transaction-isolationTRANSACTION_READ_COMMITTED/transaction-isolation
|
| We also tried an XA datasource but that gave the same
hhh. Martin, you are great. Your memory works
better than mine ;-)
So it was no deja-vu, but a real memory
Jan, so it is a regression. Could you try and the flush to the join node, (re)
compile jbpm (or that one class) and test?
| Index:
The lockMode = FORCE. This is what the debugger says.
I don't know where to look for in the database for the lock mode in the join
table???
the parentToken that will be locked has a node attribute that called Fork !!
The token that is referred to in the exception has a node reference to the
And it is indeed the parentNode that is locked, so the fork.
And the default lock is 'FORCE' which is identical to 'UPDATE' (for which
'pessimistic' in jbpm is a synonym.
UPGRADE_NOWAIT is another oracle specific one, just not sure (and no time to
find out) what the exact difference is.
@Martin,
The fix was for postgress, so I think re-introducing the flush was forgotten
anonymous wrote : If you can (still) differentiate, that's a good sign :-)
Sorry I have no clue what you are talking about
2008-12-15 14:06:07,016 ERROR [STDERR] org.hibernate.StaleObjectStateException:
Martin,
I think it looks like the same problem, will ther be a fix for this soon??
Jan
View the original post :
http://www.jboss.com/index.html?module=bbop=viewtopicp=4196529#4196529
Reply to the post :
http://www.jboss.com/index.html?module=bbop=postingmode=replyp=4196529
Yes, I will do that and let you know about the result.
Thanks for your quick response guys!
Jan
View the original post :
http://www.jboss.com/index.html?module=bbop=viewtopicp=4196537#4196537
Reply to the post :
http://www.jboss.com/index.html?module=bbop=postingmode=replyp=4196537
another thing to try (keep in mind, I do not see them as solutions!!!) is to
put a 'lockmode=pessimistic' attribute on the join node.
View the original post :
http://www.jboss.com/index.html?module=bbop=viewtopicp=4196575#4196575
Reply to the post :
anonymous wrote : Your memory works better than mine ;-)
I don't know about that, but strangely enough I see roughly the same questions
being asked at different channels by different users. Don't know yet why this
coincidentally happens, but it does make me look as if I remembered things well
Oh... yes... can you make the small unit test? I can check here with H2, hsqldb
and mysql to validate behaviour against those db's
View the original post :
http://www.jboss.com/index.html?module=bbop=viewtopicp=4196563#4196563
Reply to the post :
btw, the join code snippet I saw from you for the join is *not* jbpm 3.3!!! it
is older. Or did you copy the small code snippet from the jira issue? If that
is the only difference, there is no problem. Othewise please make sure the
correct source is used otherwise we might be hunting ghosts.
hhm Deja-vu. This was an issue long ago, but not heard
anyone about it since then. Could be that people just not do this very often.
What is your isolation level? And could you create a minimal unittest like I
described in your other post that demonstrates the problem?
I know your variables do not behave as expected in 3.2.3 (other topic) but
could can you give it a try with 3.2.3 in any way. I need to make sure it is a
regression and not something else.
View the original post :
http://www.jboss.com/index.html?module=bbop=viewtopicp=4196562#4196562
Reply to
Martin,
The token for which the update fails belongs to the fork and not the join
according to the database. Mayby this will help you solving the problem.
Jan[/img]
View the original post :
http://www.jboss.com/index.html?module=bbop=viewtopicp=4196561#4196561
Reply to the post :
The session.flush() does not seem to make any difference!
Changed the code in class Join as follows:
109 if (session!=null) {
| 110 LockMode lockMode = LockMode.FORCE;
| 111 if (parentLockMode!=null) {
| 112 lockMode = LockMode.parse(parentLockMode);
|
I've made another test with a stripped version of your process. I've removed
the decision handlers, and made a direct transition from fork to join in one of
the branches.
This is the result:
| HSQLDB: 3.2.2: OK, 3.2.3: OK
| Oracle: 3.2.2: FAILED, 3.2.3: OK
| Postgres: 3.2.2:
The version 3.2.3 has the same (faulty) result. We switched to 3.3.0 in the
hope that this problem was fixed in that version. :-((
Jan
View the original post :
http://www.jboss.com/index.html?module=bbop=viewtopicp=4196594#4196594
Reply to the post :
anonymous wrote : Deja-vu.
Isn't https://jira.jboss.org/jira/browse/JBPM-1886 the cause for your deja-vu?
View the original post :
http://www.jboss.com/index.html?module=bbop=viewtopicp=4196522#4196522
Reply to the post :
http://www.jboss.com/index.html?module=bbop=postingmode=replyp=4196522
Ronald,
the code snippet came from the source code that was shipped with the 3.3.0
GA release download. I assumed that this is 3.3.0. code!!!
Martin,
your stripped version exposes the problem correctly I think although such a
situation is hypothetical. But I think a fork that
Ronald,
Excuse me, you are right about the code snippet. I pasted the the wrong code
in here. This is the correct code:
| if ( parentToken != null ) {
|
| JbpmContext jbpmContext = executionContext.getJbpmContext();
| Session session = (jbpmContext!=null ?
39 matches
Mail list logo
