[JBoss jBPM] - Re: does this design make sense?
by twiceknightly
Hi dOoMi,
I'm not at work so I can't remember the exact details of the calls etc however it would go something like that presented below. DISLAIMER: I'm not sure if this is enough to simulate a lock an prevent concurrency issues or not.
A task is meant to be a unit of work that the user performs via the UI. Generally tasks are assigned to a pool/group. So if an individual is a member of that pool/group then they can see that task. Tasks are then pulled or pushed from the pool to an individuals personal task list to prevent multiple people picking up the task. Once on the personal task list the user then completes the task. A fairly straight forward usage would be to have a task inside a task node and, by default I believe, when you signal the token into the task node it creates the task instance. When the token leaves the task node it closes the task. There are a lot of scenarios when using tasks but I believe that is probably the most common usage.
Ok so to use a task as a lock I would propose
1. In an action handler at the start of the process a call to
TaskMgmtInstance.createTaskInstance() to create a task solely to be used as a lock. (see section 11.2.2 of the user guide)
2. Create a new group in the database
3. Assign the task to the group via TaskInstance.setPooledActors()
4. Before executing an update of the process instance, e.g. a signal, you need to make a call to acquire the lock (i.e. you need to get the task assigned to you i.e. you pull it from the group list onto your task list). This is done by TaskInstance.setActorId().
5. Determine if you have the lock. Stated another way determine if the special task is on your personal work list with a call to TaskMgmtInstance.findTaskInstancesByActorId()
6. If you have the lock then you are free to carryout your actions on the process instance.
7. Free up the lock by doing TaskInstance.setActorId(null). This effectively takes the task out of your list and puts it back on the pooled/group list.
A timer may be needed to automatically free up the lock/task if not user(Section 13.1 of user manual).
It's very crude and I'm not even sure if it would work but I would love your thought on the idea.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4163723#4163723
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4163723
18 years
[JBoss jBPM] - Re: does this design make sense?
by twiceknightly
"dOoMi" wrote : -> resources: i'm sorry, i'm new to the discussion board, too. so i have no idea where to find the original discussion thread.
|
| -> exception: the exception is caught after all in org.jbpm.svc.Services in Line 226. The original Exception is caught earlier but gets wrapped into a JbpmPersistenceException and is thrown further.
|
| -> locking-mechanism: you could also use a simple process variable to indicate the locking. as kukeltje stated the problem is the failover-scenario. what happens if the server crashes and the lock stays?
|
| another approach might be to change the isolaotion-level of the database. this way you could take advantage of the existing locking-mechnism provided by your database.
It's good to have you on here dOoMi. Thanks for the info.
I didn't think you could use a process variable to do the locking because the contextInstance, in which the variables is stored, is also a shared object like the processInstance.
What I did think you could do is create a new task in your process instance that you have to claim and have in your personal task list before you can do anything. This is analogous to claiming a lock. Tasks can have timers so if the server crashes then the timer is still in the database and will eventually timeout. When it times out the task owner will be reset to null.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4163616#4163616
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4163616
18 years
[JBoss jBPM] - Re: does this design make sense?
by dOoMi
as i see it, it works/fails like this:
1a. thread 1 opens a jbpmContext and a process instance
1b. thread 2 opens a jbpmContext and the same process instance
2a. thread 1 passes data to the process instance and gives a signal()
2b. thread 2 also passes data to the process instance and gives a signal()
3a. thread 1 processes the signal
3b. thread 2 processes the signal
---now tatata, the problem occurs---
4a. thread 1 closes the jbpmContext, this causes the jbpm-engine to commit() the changed processInstance to the database -> OK
4.b thread 2 closes the jbpmContext, this causes the jbpm-engine to commit() the chanced processInstance to the database; commit() fails, because the processInstance on the database is different than it was when it was loaded; StaleObjectStateException is thrown AND CAUGHT by the jbpm-engine -> BAD, because the caller does not notice; data is lost, no retry can be scheduled
-> in my opinion the solution could be a method to tell, when optimistic locking failed to be able to retry. that's what i tried to do in my code.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4163497#4163497
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4163497
18 years