anonymous wrote : but IS it started?
Nope. I ran our application in the Eclipse debugger and did not see any
reference to LockMonitorThread. I also generated a thread dump of our
application, LockMonitorThread does not appear there either. (The dump file is
1800+ lines, I can email it to anybody that is interested in double checking)
Note that we are not using a J2EE server. We are running this as a standalone
Java application.
So with respect to the comment:
anonymous wrote : Isn't this the same as transactiontimeouts work in j2ee?
Roling back something that just took to long but finished without an error
Maybe so, but we aren't using this in a J2EE server. In any case, this isn't a
huge issue for us at the moment since we can simply increase the maxLockTime to
be the Integer.MAX_VALUE
Philosophical commentary follows (feel free to stop reading)
So here is my opinion. Any comments and feedback would be appreciated. This is
mostly intended to help me understand the jBPM design intent with respect to
rolling back successfully completed activities simply because they took too
long.
So if the node completes succesfully, the transaction shouldn't rollback. Since
the timeout doesn't cause the thread (execution context / token) to be aborted
the system is doing the work anyhow. You aren't saving anything by considering
it a failure. If the intent is that it should be considered an error if a
sequence of nodes takes too long to process, then you probably should somehow
abort the processing rather than let it continue. Now what would happen (if the
LockMonitorThread is actually running) another thread would acquire the job and
start running. Now you have two threads actively processing the same path.
(Maybe this is a mute point since I think some of the async / JobExecutor stuff
is changing post V3.2.1?)
Wouldn't be so bad if everything our process did was inside the same database
and transaction and didn't have any external side affects that are either
difficult or impossible to rollback. So with this behavior we somehow would
need to add our own code to test for exceeding maxLockTime and that a rollback
was going to occur and we would have to figure out how to detect that jBPM
decided to roll things back and compensate or reverse the external actions.
For example one of our steps loads millions of rows of data, impractical to
have in a single transaction and rollback the data. Our code doesn't get any
notification that the rollback occurred so if we have no opportunity to execute
compensating code. Maybe the design intent is that everything should be done
in such a manner that it is controlled by a transaction monitor. This is
generally a bunch of non-trivial work for non-database related activities.
So again, I still don't see the value in having a maxLockTime for a job if you
are going to let the job run to completion w/o aborting it and allow the system
to attempt to process the path again even though it is still currently being
processed. This could lead to all kinds of chaos.
View the original post :
http://www.jboss.com/index.html?module=bbop=viewtopicp=4084509#4084509
Reply to the post :
http://www.jboss.com/index.html?module=bbop=postingmode=replyp=4084509
___
jboss-user mailing list
jboss-user@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jboss-user
