[Design of JBoss jBPM] - Re: releasing 3.2.Beta1
by tom.baeyens＠jboss.com
"david.lloyd(a)jboss.com" wrote : As far as the tasklist goes: what I've implemented isn't really a user task list, it's really a "manager" task list , with all tasks for all users being listed. This is something else that will be changed I expect. I think that in the end, both variations will exist, but one will be chosen based upon user role; or perhaps the manager version will be in a separate set of screens and the manager will have access to both. I can easily split it out though.
|
please fix this so that the user task list only shows the tasks DIRECTLY assigned to the logged on user.
to have the manager task list, i want a search for tasks later as a separate functionality from the user task list.
"david.lloyd(a)jboss.com" wrote :
| The group task list still needs more testing.
|
keep that for later. not important for this beta release.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3997961#3997961
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3997961
19 years
[Design of JBossCache] - SELECT FOR UPDATE semantics
by bstansberry＠jboss.com
I know I raised this issue somewhere before, but can't find it, so here we go again...
We're about to finalize the 2.x API; before we do, can we add something that provides semantics similar to SELECT FOR UPDATE, i.e. ability to do a read, but acquire a WL in the process? As it is now, there is no clean way for a tx to read a node and then be confident it can subsequently write to that node. It's possible for another tx to also get a RL on the node, which will prevent the first tx getting the needed WL.
This would be very helpful with http sessions that are shared between webapps, where I'd like to use a cache node to store the session, and use the node lock to prevent concurrent access to the session. The natural flow is to do a read, and then *maybe* do a write later if the session data has changed. The RL from the initial read doesn't provide a strong enough semantic. To work around that I'd need to do some hack like doing a put() at the beginning w/ a dummy key/value pair.
I've seen other threads that raised similar requirements.
I think doing this should be pretty simple. I believe it only applies to pessimistic locking. If we implemented it as an Option (e.g setReadForUpdate(boolean)) it would only affect the pessimistic lock interceptor. That interceptor would, on a get request, check the option and if present:
1) If the requested node does not exist, create it, like it does with a put.
2) Acquire a WL instead of a RL.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3997944#3997944
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3997944
19 years
[Design of JBoss jBPM] - Re: releasing 3.2.Beta1
by david.lloyd＠jboss.com
"tom.baeyens(a)jboss.com" wrote : also i just saw a potential minor problem with this. i just started the websale process. and as the feedback on starting a process instance, i got the 'New Tasks Created' screen with in the table, '(nobody)' in the 'Assigned To' column. When i clicked the task, it appears to be assigned to ernie (the initiator) as to be expected from the process definition.
This is an oversight on my part - I'm pulling the assigned actor from the TaskCreateLog entry. Apparently the actor ID is always null here (the actor ID isn't assigned until the subsequent TaskAssignLog entry). I'll just pull the actor ID from the task itself, that way it won't be wrong.
As far as redirecting to the task form: That's a navigation bit that I've left undone. In my estimation, users probably want to go to the task form directly, but managers may want to see the task list to know that there are (or are not) other tasks for other users. When the SEs give their feedback, I'll have to assemble a list of criteria that I use to choose how navigation goes.
As far as the tasklist goes: what I've implemented isn't really a user task list, it's really a "manager" task list , with all tasks for all users being listed. This is something else that will be changed I expect. I think that in the end, both variations will exist, but one will be chosen based upon user role; or perhaps the manager version will be in a separate set of screens and the manager will have access to both. I can easily split it out though.
The group task list still needs more testing.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3997924#3997924
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3997924
19 years