Submitted by Syd Nicholson on Mon, 02/21/2011 - 14:29
Forums
IceBreak

I have a question about comitment control under Icebreak.

1. Is it best to start/end commitment control on every transaction?
2. If commitment control is started on one transaction -- will it carry forward to all susequent transactions in the session?

Regards
Syd

 

Niels Liisberg

Mon, 02/21/2011 - 14:31

Permalink

Hi Syd,

Commitment control only works if the server runs in multi-thread mode - on the otherhand, then it works quite well ... So yes - start the unit-of-work in a program on "top level" - i.e. your logon like this:

 

  if sesGetVar('commit-active':'false') = 'false';

    exsr StartCommit;

    sesSetVar('commit-active':'true');

 endIf;

Now if your session times out, the session variabel diseapears and the unit of work is rolled back. 

Btw - hint - Don't use bool/indicators with session variables....

Hi Niels,

Observation on commitment control.

It would appear that commitment control has already been started by the IceBreak server. If I try to use STRCMTCTL, then I get an error stating that commitment control is already active.

Is this true, or is commitment control started automatically some other way??

Regards
Syd

Syd Nicholson

Tue, 03/01/2011 - 14:33

Permalink

Just trying to get things into my head.

1. When a new IceBreak session starts my initial program (index.rpgle) tries to do a QCMDEXC with STRCMTCTL.

An error message stating that commitment control is already active is issued?? This is the case even if this is the very first instruction in the program.

2. Needless to say -- if somebody navigates away from the session to some other site, then returns to IceBreak, index.rpgle will run again. under these circumstances and MONITOR:ON-ERROR:ENDMON group is used to capture the expected error with STRCMTCTL. Commitment control is, of course already running.

3. I can use commitment control without STRCMTCTL. Currently, none of my programs explicity start commitment control, yet there is an active commitment environment. I don't understand how this can be.

4. It is difficult to start a new session - my current session ID dates from 15th Feb (2011-02-15-17.22.17.900001). In that time IceBreak has been ended several times, indeed the iSeries has been powered down at least three times. The PC has also been shut down several times.

Are the session details held in cookies in the browser?? Could I force a new session by deleting the cookies??

Would a completely new session have no commitment control environement??? Could my current commitment environment be a hang over from some action taken several days ago, even if the Icebreak server has been ended and the machine powered off???

Regards

Syd