JBPM use Hibernate to write to the DB, Even if the transactin is NOT_SUPPORTED
it not write immedetly to the DB but rather wait for flush to write to the DB.
In some cases the Hibernate session of JBPM is different than the Hibernate
session of the application.
Therefore if JBPM needs to write s
efip10,
Sorry, I used too broad a brush.
At least in some cases, the behavior I described is dependent on the isolation
level selected. If at least level 2 ("read-committed") is selected, then I
think it works as I described, if the database supports it. I believe that
row-locking is used in
Ed,
I am not sure that you have a point here, as JTA can only guarantee the fact,
not the order. I.e. it is either (the rows are saved && JMS message is sent) or
(the rows are ! saved && JMS message is ! sent). However, JTA cannot guarantee
the order (first the rows are saved, then the message
efip10,
On thinking about your problem some more...
Are you using JTA transactions?
AFAIK, an MDB message sent as part of a JTA transaction will not actually be
sent until the transaction is committed. In this case, if the MDB were created
as part of the transaction that's saving the ProcessI
As I have tried to build the minimum setup, I come to think that it is not JBPM
problem.
Let's put it this way: I create a row in DB, send a JMS message, and create
another row. In the end I commit my transaction.
In the meantime my message is processed, and there is a query to the DB for the
please use a new topic for this. This topic is on concurrency within one
process, not for concurrent instances of a process.
View the original post :
http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4065460#4065460
Reply to the post :
http://www.jboss.com/index.html?module=bb&op=postin
I have found a problem with instances of processes. When I start multiple
instance of same process, JMSIntegrationService mix the instances inside the
Token variable. Two instances started at the same time and in one instance flow
did not continue and other instance activity is mixed with curren
Best is to extract a minimum setup that produces the problem and attach that to
the JIRA issue (http://jira.jboss.com/jira/browse/JBPM-983).
Regards,
Koen
View the original post :
http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4064918#4064918
Reply to the post :
http://www.jboss.co
Koen,
Since there's quite a lot of stuff, I'd rather have it sent by email than
posted. May I use [EMAIL PROTECTED] for that?
Thanks
View the original post :
http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4064503#4064503
Reply to the post :
http://www.jboss.com/index.html?module=bb
Koen,
See also
http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4008324#4008324
It's the same thing, I think. Unfortunately, no JIRA or unit test there,
either.
-Ed Staub
View the original post :
http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4064497#4064497
Reply to the p
efib10,
can you post the details of your processdefinition and your client code? we are
investigating these serious concurrency issues that exist in jBPM at the
moment. There are two failing jUnit tests in the org.jbpm.job.executor package
(JobLoadJoinTest and JobLoadSubprocessTest). As you kn
"kukeltje" wrote : Ed,
|
| Will putting an async=true on the node realy force a commit? That has to be
documented well then (rollback
| 's further on in the process a rollback will not be possible then) This is
not a problem if the process has to wait for the return value of the async
mes
FYI guys, in the meantime I have a workaround of using
ctx.getJbpmContext().save(ctx.getProcessInstance())in my action - before
sending a message; all this works only because of
@TransactionAttribute(TransactionAttributeType.NOT_SUPPORTED) on MDB, so every
save() also commits.
I am not sure wh
Thanks for the replies, guys.
I tried to put async=true on all of my message-firing nodes, and actually that
does not help. I can see in the log that context.close() is finished after the
message arrives and the instance is loaded.
Except for using a voluntary Thread.sleep(), does anyone have
Ed,
Will putting an async=true on the node realy force a commit? That has to be
documented well then (rollback
's further on in the process a rollback will not be possible then) This is not
a problem if the process has to wait for the return value of the async message
node.
If it is not saved
I'm not sure, but I think that if you mark your message-firing node as
'asynch="true"', this will force a commit and take care of the problem.
If you happen to be firing the message from the node-entry event, this won't
work; you'll need to mark a prior node, perhaps introducing a dummy one just
what in your view is a simple continous flow, is in fact straight trough
processing. BUT with influences from external systems. This is an issue
currently under debate/investigation.
Saving the process before reading it is done when closing the context. So the
sooner you do that, the soone
Forgot to mention: there are no tasks, joins/forks, or child processes used in
my flow. It is really, really simple continuous flow.
View the original post :
http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4063579#4063579
Reply to the post :
http://www.jboss.com/index.html?module=bb&o
18 matches
Mail list logo
