| Author |
Message
|
| kriersd |
 Posted: Wed Jun 09, 2004 1:35 pm Post subject: multiple container items in the description field |
 |
|
Master
Joined: 22 Jul 2002
Posts: 209
Location: IA, USA
|
Is it possible to put multiple items in the description field?
_________________
Dave Krier
IBM WebSphere MQ Workflow V3.4 Solution Designer |
|
| Back to top |
|
 |
| manoj |
| Posted: Wed Jun 09, 2004 1:52 pm Post subject: |
|
|
Master
Joined: 30 Jan 2002
Posts: 237
Location: Virgina
|
Yes...use %
e.g : %item1%item2%
you may want to put a "|" in between to seperate them..like
%item1%|%item2%
hope this is what you want ....
_________________
-manoj |
|
| Back to top |
|
|
| kriersd |
| Posted: Wed Jun 09, 2004 1:57 pm Post subject: |
|
|
Master
Joined: 22 Jul 2002
Posts: 209
Location: IA, USA
|
Thanks Manoj
I thought so, but asking the question sometimes builds confidence. 
Any idea what the performance hit will be?
_________________
Dave Krier
IBM WebSphere MQ Workflow V3.4 Solution Designer |
|
| Back to top |
|
|
| manoj |
| Posted: Wed Jun 09, 2004 2:01 pm Post subject: |
|
|
Master
Joined: 30 Jan 2002
Posts: 237
Location: Virgina
|
I don't think there's any performance hit just doing this...the Entire string is stored in the Database column DESCRIPTION in the workitem table...
only performance problem will come if you code your filter using
DESCRIPTION LIKE 'appid|appnum*' something like this will cause a table scan.....if you use this , when your number of workitems increases your performance drops
_________________
-manoj |
|
| Back to top |
|
|
| jmac |
| Posted: Wed Jun 09, 2004 4:06 pm Post subject: |
|
|
Jedi Knight
Joined: 27 Jun 2001
Posts: 3081
Location: EmeriCon, LLC
|
Dave:
I agree with everything manoj has said.... I would just like to add that there is a slight database footprint issue with multiple items in the description. In the "ancient" (no longer supported) Sizing spreadsheet to calculate database size one of the items you had to specify was average description size.
I take it by performance hit you meant CPU hit and I agree there is not much there.
_________________
John McDonald
RETIRED |
|
| Back to top |
|
|
| kriersd |
| Posted: Thu Jun 10, 2004 7:50 am Post subject: |
|
|
Master
Joined: 22 Jul 2002
Posts: 209
Location: IA, USA
|
Thanks guys,
Just a little background here. I was approached due to a Workflow performance problem in one of my business areas. They have a custom written thick client application, which displays 12 data container fields in the work item list along with a few of the normal work list columns. When I first heard of a performance issue I assumed we needed to tune the server and stripe the disks. That did help, but it didn't help enough. After maximizing all the system tuning options, I started to look more at the thick client application. The problem is that the application is retrieving the work items and then making another trip back to the database once for each work item to get the data container information. I believe the application is making one call to get the (x) number work items, then going back to the database once for each work item to get the data container for each work item. Now multiply that by the number of users doing a refresh and "BANG" you have a performance problem. So I am trying to look for alternatives to accomplish the same results. My thought is that we can put the 12 data container elements in the description filed separated by a delimiter. This way the application only has to make one call to the database. I know this is an ugly solution but in a pinch, I think it may just work.
Any other ideas.
_________________
Dave Krier
IBM WebSphere MQ Workflow V3.4 Solution Designer |
|
| Back to top |
|
|
| jmac |
| Posted: Thu Jun 10, 2004 8:03 am Post subject: |
|
|
Jedi Knight
Joined: 27 Jun 2001
Posts: 3081
Location: EmeriCon, LLC
|
Dave:
A couple of things.
1) Going to the Database for container items has always been a bad idea. If I read your post correctly its not quite as bad as you think. I believe that there is a single client/server call to get ALL of the container items for a given workitem, of course I could be wrong so don't take this as gospel. If you need the absolute truth I would send a query to the lab.
2) Your circumvention is the typical one used, however, you need to be careful since the total length of the Description is limited (1024 bytes is what sticks in my head, but not certain here). If you have long values in the container fields you may have a problem, which could be why it was done this way in the first place.
GOOD LUCK
_________________
John McDonald
RETIRED |
|
| Back to top |
|
|
| manoj |
| Posted: Thu Jun 10, 2004 8:43 am Post subject: |
|
|
Master
Joined: 30 Jan 2002
Posts: 237
Location: Virgina
|
John,
I believe each getXXX() method on the workitem container calls the server. Please post if you find otherwise from the lab
thanks
_________________
-manoj |
|
| Back to top |
|
|
| hos |
| Posted: Fri Jun 11, 2004 12:07 am Post subject: |
|
|
Chevalier
Joined: 03 Feb 2002
Posts: 470
|
No, getXXX calls on a container are local (accessor) calls served by the API. Workitem::InContainer() is a server (action) call, however.
To solve the problem you could also check whether the usage of a global data container helps. If some of the 12 container values are 'fix' they could be moved to the GDC. There is an API method to obtain the global data container for a process instance. |
|
| Back to top |
|
|
| manoj |
| Posted: Fri Jun 11, 2004 5:43 am Post subject: |
|
|
Master
Joined: 30 Jan 2002
Posts: 237
Location: Virgina
|
Thanks for the getter method clarification
_________________
-manoj |
|
| Back to top |
|
|
|
|
