| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
  |
|
| Virtual User Strategy - Collisions Transferring Items |
« View previous topic :: View next topic » |
| Author |
Message
|
| JKehoe |
 Posted: Wed Aug 10, 2005 9:09 pm Post subject: Virtual User Strategy - Collisions Transferring Items |
 |
|
Novice
Joined: 10 Aug 2005
Posts: 20
|
Hello,
I have implemented a Virtual User strategy and for the most part, it works very well. However, I am having a problem when two users hit my transfer item code at the exact same time. Since every user has authority to transfer to any other user (one of my requirements), I am having a collision problem where a workitem will transfer to USER_1 and then is immediately transferred to USER_2. At this point, USER_1's worklist thinks it has the workitem, but when the user tries to check it out, they receive the "State does not allow this action" error. Here is my transfer item code:
| Code: |
public boolean transferItem(WorkItem wi, String newOwner, String expectedOldOwner) {
try {
if( !this.isCheckedOut(wi) && wi.owner().equals(expectedOldOwner) ){
wi.transfer(newOwner);
return true;
}
} catch (FmcException e) {
// ignore exception if user already owns the item
if (e.rc == FmcException.FMC_ERROR_OWNER_ALREADY_ASSIGNED ) {
} else {
System.out.println(e.messageText);
throw new RuntimeException();
}
}
return false;
}
public boolean isCheckedOut(WorkItem wi) {
try {
return wi.state().value() == ExecutionState._CHECKED_OUT;
} catch (FmcException e) {
e.printStackTrace();
throw new RuntimeException();
}
}
|
The expectedOldOwner is the Virtual User and the newOwner is the person currently logged in. Basically, two different users are hitting this method at the exact same time passing in the same WorkItem and both times True is returned.
Has anyone else run into a situation like this? The only solution that I can come up with is to double check a user's worklist items before rendering the webclient page, but that would obviously decrease performance. If anyone else has ideas on how I can improve this, I'd be very greatful.
Thanks in advance,
Josh |
|
| Back to top |
|
 |
| hos |
| Posted: Wed Aug 10, 2005 11:57 pm Post subject: |
|
|
Chevalier
Joined: 03 Feb 2002
Posts: 470
|
Hi,
you can avoid this situation if User_1 and User_2 only have workitem rights for Virtual_User and NOT for each other's workitems. However then you loose the substitution feature. |
|
| Back to top |
|
|
| JKehoe |
| Posted: Thu Aug 11, 2005 3:44 am Post subject: |
|
|
Novice
Joined: 10 Aug 2005
Posts: 20
|
| We would also lose the ability for any user to transfer work items to any other user. Otherwise, you're right, that would do the trick. |
|
| Back to top |
|
|
| jmac |
| Posted: Thu Aug 11, 2005 5:30 am Post subject: |
|
|
Jedi Knight
Joined: 27 Jun 2001
Posts: 3081
Location: EmeriCon, LLC
|
Interesting issue...
When was the last time the wi in question was updated? Remember you are working with a transient object here, and perhaps if you put a wi.refresh() call at the top of the method it would help.
You can always add a test to ensure that the current user is the owner prior to issuing your checkoug.
_________________
John McDonald
RETIRED |
|
| Back to top |
|
|
| JKehoe |
| Posted: Thu Aug 11, 2005 8:08 am Post subject: |
|
|
Novice
Joined: 10 Aug 2005
Posts: 20
|
Thanks, John.
I synchronized the block of code that does the transfer (specifically, the If block in my code section). I am also now refreshing the work item like you suggested and in my limited testing, it appears to be working better. I'm going to schedule some time for a full load test, so hopefully it will continue to work and the synchronized block will not cause to big of a bottle-neck.
For a temporary fix, I have code in the check out command to catch any FmcExceptions and redirect back to the webclient, but I don't want this to happen very often because it slows processing time.
I'm still interested to hear other ideas and opinions!
Thanks again,
Josh |
|
| Back to top |
|
|
| hos |
| Posted: Fri Aug 12, 2005 9:02 am Post subject: |
|
|
Chevalier
Joined: 03 Feb 2002
Posts: 470
|
Josh,
you can try the following to avoid the expensive wi.refresh() server call:
for each workitem of the Virtual User provide a 'synchronizer token' in your application (array). Before a user can transfer a workitem he must first request and lock the corresponding synchronizer token. This implements kind of locking mechanism in the client that MQWF leaves up to its servers. |
|
| Back to top |
|
|
|
|
|
| |
|
Page 1 of 1 |
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
|
|
