Terminate the application (develop using PB 12.5) after certain time of user inactivity.

[Former Member]

Dear All,

We want to terminate our PowerBuilder 12.5 (PB12) application in the following scenario.

• If there is no user activity or no process (front-end / back-end) is getting executed for certain period of time then the system will terminate itself.
• While terminating the application, the system will close database connection(s) and opened screen(s).
• After termination, the system will display the login screen through which on successful login, the user will able to open the application once again.

To achieve the above goal we have write the following script

Script written in the application idle event

Rollback;

Disconnect;

Idle(0)

Restart()

Following code in application login screen OK button

//Call idle event after 2 minutes of user inactivity

Idle(120)

We have checked the above logic in PowerBuilder 5.0, and found ok.

But when we are testing it in PB 12 environment, we found that it is improperly terminating the application. Following are the scenario

1. A report require 4 minutes to generate (require 4 minutes to display the data on the screen after click the retrieve button).
2. Using the above report we have check the application termination logic.
3. After click on the retrieve button for the above report we have not done any user activity (e.g. mouse movement, mouse click & keyboard activity etc) in the application.
4. But we found that after 4 minutes system display the report data on the screen & immediately (within a fraction of second) terminate the application.

Our Perception of Idle process in PB 12.5

1. It will behave like PowerBuilder 5.0 application.
2. For the above scenario (report generation) system will start count the user inactivity time after display the report data on screen. Means system will terminate the application after 2 minutes of display the report  data on screen

Request you to help me to resolve this issue.

Thanks & e-Regards

Avishek

[Former Member · Accepted solution]

Chris has missed the point... 

The problem isn't that the report takes 4 minutes to run, (and it's highly unlikely that UTF-8 to UTF-16 conversion is adding any substantial delay to the report process) - it's that the idle timer is expiring in the middle of that long report being processed. 

Windows is queueing up the application idle event, and it's getting processed as soon as the application regains control.  You don't want the processing time for the report to "count" against the 2 allotted minutes for sitting idle, since there's really nothing else for the user to do until that report finishes.

The easiest option is simply to disable the idle timer prior to running "long" reports, then re-enable it once the report finishes.  Then you can start the process of making your reports run faster - probably by tuning the SQL of the report query.

-Paul Horan-

[Former Member · Accepted solution]

Hi Paul;

  No, I did not miss the point. If you read my replies carefully - I advised Avishek to turn off the IDLE timer at the RetrieveStart event of the report DW/DS and then on again at the RetrieveEnd event.

  FYI: PB's performance did take a nose dive in the Unicode implementation. I documented this extensively for Sybase Technical support when I was on contract at Shared Service Canada for 2.5 years. Many of our clients were migrating from PB 8/9 to PB 10.5/11/11.5 and most encountered slower result set processing times. I even ran the application profiler on the PB 8/9 application and then again on the PB 10/11 application and proved the slower response times were in the DBMS interface driver and they way PB handled text (double-byte) processing.

  Note: MS-SQL Server result set processing is easier on PB as this DBMS works in UFT-16 mode  like Unicode based PB versions. The Unicode DBMS performance hit was the worst on the Oracle DBMS in our extensive testing.

Regards ... Chris

[Former Member · Accepted solution]

The OP was not very clear though. It states that it is ok in PB5.0 but did not mention that the query in PB5.0 was quick or still took 4 minutes or so...

If the query in PB5.0 still took longer than 2 minutes and the idle timer was still ok, then maybe something is implemented differently with regards to the idle event in PB5.0 vs PB12.5.

Modifying the code for each retrieve is quite tedious and tricky as you don't want to cancel the idle timer on all retrieve situations. You only want to cancel it on long queries, so  modifying the ancestor script does not work all the time.

The OP is looking for a quick way, so the prompt, I think is an option.

[Former Member · Accepted solution]

Hi Neil;

You present another good alternative for sure!  

Happy New Year!  

Regards ... Chris

[Former Member · Accepted solution]

Thanks Chris. Happy New Year to You too!

Wish all the best for us PB'ers in 2015 and the years ahead...

Best Regards,

Neil

[Former Member]

Thanks chris for your feedback. Following is my analysis

1. In every screen before process start I have manually turn off the idle detection.

        I have to write idle(0).

   2.  For the above screens after process complete I have to turn on the idle detection.

        I have to write idle(300) for application termination after 5 minutes of user inactivity.

   3.  The above code (point 1 & 2) will be written for the screen those are not inherited from the                     ancestor.

   4.  Those screens are inherited from ancestor then the idle detection turn on / off will written in           ancestor script. But this process is applicable for data retrieval, but if some PB scripts are call           backend procedure / function / package (long running) then writing script in ancestor will not           solve the purpose. Because if I write a code (idle detection turn on / off) in retrieve start event in           ancestor script but the backend object are call from a button then it is not solve the purpose. For           this scenario (call backend object) I have to write before call the object and after complete the           process.

Thanks Garcia for your feedback, please help me how do check the ‘sqlca is busy ‘from PB          script. If we use other custom / user defined transaction object for this case how to I check it is          busy.

Thanks

Avishek

[Former Member]

FWIW: I think handling the IDLE ( ) in the DW/DC events would be a lot easier to implement. Just my $0.02 on the matter.

Good luck!

[Former Member]

Dear All,

Once again I came back in this discussion, because I have done the impact analysis / discussion with business regarding the changes. We found the following problem

1. Coding effort in terms of resource utilization will be high.
2. In the above period (we will do the modification) application enhancement will stop.
3. In application all window is not inherited from a single (or two three) ancestor window, so it difficult to write a code in ancestor level which will be applicable throughout the application.
4. If we change for individual screen level then in future we have to remember for new screen also (it will be a continuous job).

For the above problem to resolve this issue from application level, means can it be possible to write a code in application level or from a central point other than window level.

Please help me to resolve this issue.

Thanks

Avishek

[Former Member]

Hi Avishek;

  IMHO - you will need to explain exactly what your analysis found and what coding changes you recommended before we can comment further.

Regards ... Chris

[Former Member]

I don't know how to do this yet but I think this is worth looking for as an alternative solution to your problem.

Look for a way to determine that sqlca is busy or having a database activity during the idle timeout, then don't restart.

[Former Member]

My suggestion is to reconsider the idle event not to disconnect and restart right away. If you could allow the user to respond to a prompt whether or not to restart the application, I think that would do it.

For example, when the 2 minute idle time has lapsed, show a prompt and extend the idle time 1 more  minute. If the user responds to the prompt, then the idle is cancelled. If the user does not respond to it within a minute, then the application can restart as it indicates there is no user currently interacting with the application.

Just my 2 cents...

[Former Member]

Hi Avishek;

    I use this approach in many of my applications and it works great in PB 12.1, 12.5.1 and 12.6.

    I suspect that you might be encountering an issue with the performance of PB 12.x vs 5.x as PB 12.x are Unicode based vs ANSI based for v5. Since PB 10.x, PowerBuilder's Unicode implementation is UTF-16LE or also know as double byte. Whne dealing with a UTF-8 DBMS, PB now needs to convert the result set to UTF-16 which will take longer. Also, when parsing result sets in PowerScript - text handling methods will take longer. So it is quite possible that during the Result Set processing you do in fact exceed the 120 seconds Idle timer.

   My suggestion would be to disable the IDLE timer on the RetrieveStart event of your report DataWindow and re-=enable it on the RetrieveEnd event. That should circumvent the scenario you describe.

HTH

Regards .... Chris

[Former Member]

Thanks Chris,

As per your suggestion i have to write the code for each report & process.

In our application we have more then 100 report & 50 individual process.

For the above solution the whole system will be impacted & development time will be high.

Can it be possible to resolve it any other way.

I mean without writing code for individual process / report, can it be possible to write a code which is applicable for whole application.

Thanks

Avishek 

[Former Member]

   Hopefully, you have one DataWindow Control and one DataStore ancestor where you can implement this change!  

  If not, you might have to rethink the IDLE event logic to handle a longer period between timeouts.