Hi all,

I'd like to know at which point in an mq client web application I have to invoke the logoff() method of an ExecutionService instance().

The programming guide just says 'At the end of your program, you log off in order to close the session to the server.'

But what is the end of a programm within a web application?

Can I leave the MQ session open as long as the HTTP Session (=application session) is valid?

Will I get problems with multible, parallel MQ session instances of the same user id?

The safiest way is to logon/logoff at each mq action call, but I can't beleave that this is a 'best practice' recommendation.

Leaving the session open over a certain time (minutes) we are facing consistency problems, e.g.

(1) saving (executionService.create()...) a transient worklist -> an OID is returned; no exception is thrown
(2) I can use this WorkList instance, retrieving work items, ..., all works fine
(3) Accessing the MQWF Web Client I can not see this worklist
(3) loading (executionService.persistentList(...)) this worklist within our application with the OID (1) fails with an 'not found' error (in fact, the executionServer dies, but this problem is part of an separate thread)

At the end, I was not able to find any recommendations, how the handle the ExecutionService instance within a web application.

For performance reasons we would reuse this instance as long as possible.

For any recommendations or links, I would be grateful,
thanks
Oliver

Hi

not quite sure whether I completely understand your scenario.

Basically MQWF has the concept of a session. A session is bound to a
UserId which is usually a physical person.
An MQWF session is implemented by an MQ connection. While your web
application virtually runs 'forever',
you should keep the session alive as long as the related user has some
work to do.

This is fairly simple if the UserId is an existing person: this person
comes to work, logs on to the web application,
respectively to the MQWF server, does his job and eventually logs off and
leaves the workplace.
If the UserId is a conceptional way of grouping work, it is the same
story, except that you have to take care
that you do not work concurrently on the same object in different threads.
With object I mean ANY transient API
object (ExecutionService, Worklist, etc.)

What you seem to do is to transfer objects using the Persistent Object
APIs.
This concept is described in Chapter 13 of the Programming Guide: Steless
server support.
Although it is designed to deal with multiple processe (JVMs in your case)
it is applicable in a single
process, also. You have to ensure threadsafeness, however. E.g. do not
re-create an ExecutionService
from an existing ExecutionService via setSessionContext() and then use
both objects in parallel.

Hope this helps

Volker Hoss
IBM WebSphere Process Server Development

... please, just ignore the given example, the reason of this was a stupid programming error ;-)

But the general question still remains:

Is it recommended/possible to link the lifecycle of the mq user session (via executionService object instance) with the web user session?

Will there be problems by keeping the mq user session open over a certain period of time (e.g. 30 minutes) without facing consistency problems?

Thanks,
Oliver

Volker,

thank you for your reply.

You are right the UserId is meant to be a real person.

We don't want to "recreate" the ExecutionService either, we just have to take care about the possibility that on MQWF user with a certain UserID can be logged on with multiple (client) sessions on MQ.

From your post I understand, that the approach we are using (keep the mq session connected as long as needed) is from the performance point of view the right approach.

Thank you for your help.

However, during the (ongoing) development we encountered sometimes the problem, that -given following code- the 3rd step failed with an FMC00106E error; "User not logged on".

Step (1) - create/locate service facade
****************************************

ExecutionService executionService = $MCONTEXT$.getServiceFor($MYUSERID$);

// not yet initialized; create a new one ...
if (executionService == null)
{
Agent agent = new Agent();
executionService = agent.locate("", "");
$MCONTEXT$.setServiceFor($MYUSERID$, executionService);
}

Step (2) - check whether we need to log on
******************************************

// test, whether we are still logged on
if (!executionService.isLoggedOn()) {
executionService.logon2(user pwd, SessionMode.PRESENT_HERE, AbsenceIndicator.RESET);
}

Step (3) - just do some work ...
*********************************

// load worklists
WorkList[] lists = executionService.queryWorkList(...);

From my point of view, 'isLoggedOn()' not really checks whether the connection to mq still exists or not. Maybe it just checks whether the execution instance has got an valid user id being passed via the logon() method of the same instance or so.

I'm not sure what the reason of this might be: MQ Connection/Session timeout; multiple logon with different SessionModes; MQ Restart during application lifetime; .... I don't know.

We never encountered this "problem" with our previous application version, where an ExecutionService object never got reused but every time newly allocated.

The "problem" seems to vanish as well, once we explicitly logon/logoff during each mq action call, which we don't really want to do.

This "problem" was mainly the reason to ask for the validity of our approach, so hopefully this is just an development issue.

Hopefully ...

Thank you,
Oliver

Oliver,

you seem to have overlooked the meaning of the SessionMode parameter in
the logon() call.
PRESENT_HERE means that you want to have only a single session for this
UserId.
It will force a logoff call for any other existing (PRESENT) session of
this UserId.
You need to use Default session mode if you want to have more than one
session for a UserId.

In addition you need to understand, that isLoggedOn() is a local call, not
a server call.
The transient API object is not aware of the forced logoff that happened
on the server and will return true.
You'll need a refresh() call to synchronize the transient API object with
the database content in such a situation.
See the Programming Guide for details.

Volker Hoss
IBM WebSphere Process Server Development

Volker,

thank you for your reply.

I already had my doubts by using this SessionMode for this approach (this was the way the old application version was working).

Thanks for the hint.

We already implemented a fallback by calling the refresh() method.

However at least for the scenario of a restarted execution server this method call itself throws the FMC00106E error anyway.

So as a more "sophisticated" fallback solution we will possibly catch this exception and logon again in this case ... ;-|

It is right, that by using the defualt session mode we will not longer face the FMC00106E problem, but saying a user works with our application and uses another mq client application (e.g. MQ Workflow Webclient in FORCE-LOGON mode) which might use the PRESENT_HERE mode.

At the moment I see no proper way to check in MY application whether I can rely on MY transient ExecutionService Object or not.

If a method would exist which checks the validity of the user session even with an action call to mq - if necessary - that would be quite nice and a programming by exception would not been needed.

Anyway,
many Thanks for your help,
Oliver

Oliver,

one last thing: PRESENT_HERE does NOT logoff any DEFAULT session
- only a PRESENT or PRESENT_HERE session.

Volker Hoss
IBM WebSphere Process Server Development

Hi Volker,

thanks again, I did not know that fact, although I have read the chapter about logon() several times.

Looking again at this page I now discovered the important words which I might have overlooked the previous times:

"The present here option can be used, to force THAT OTHER PRESENT session logoff ..." (p 377)

Sorry.

We now are sure that everything will work fine, the unit test which previously failed is now working with no "exception fall back solution", many thanks again for your help.

Hopefully I was not to annoying ... ;-)

Regards,
Oliver