1 Reply Latest reply on Oct 17, 2013 10:59 PM by Michael Ferrante-Oracle

    locks while in Forms 11g


      we have a scheduled job that runs and deletes certain records and inserts others..

      for years, this has worked while users were in the table via oracle forms 10g


      after upgrading to forms 11g the tables are locked while users are in the forms and the scheduled job will fail, causing many other issues..


      I'm sorry, but my programmers have not given me any further details that I can use to troubleshoot the issue..


        • 1. Re: locks while in Forms 11g
          Michael Ferrante-Oracle

          The record locking behavior of Forms has not really changed since 10.1.2.  So, if you are seeing a difference in behavior there is more to the story.  For example, it is possible that for some reason you are ending up with orphaned runtime (frmweb) processes on the server.  This could result from users closing the browser while the form is busy.  It could also be caused by network issues or a variety of other possibilities.  The point is that if records were locked by a user and their session does not terminate in a clean manner, those locked records will remain locked until their session terminates.  In most cases, this is handled by FORMS_TIMEOUT.  The default value is 15 minutes.  This means that after 15 minutes, if the runtime process has not heard from the client it will be terminated.  However, in some cases, if the form was busy when the client vanished, the runtime may go into an unstable state and not be able to shutdown.  Unfortunately, little can be done with this.  Those processes will need to be killed manually.


          My recommendations:


          1.  Never set FORMS_TIMEOUT to a value too large.  The longer an orphaned process remains on the server the longer it will waste resources.  Generally the default value is perfect.

          2.  Never set the Forms HEARTBEAT value to something larger than FORMS_TIMEOUT.  This can cause orphaned runtime processes when the client is killed.

          3.  Ensure that you are running the latest patch release for your version.  In other words, for Release 1 you should have and for Release 2 you should have

          4.  Although it is not required, regenerating your X files (fmx, mmx, plx) after installing a full patch is a good practice.  Also including the compile_all=yes option when generating those files will help to ensure a proper internal cleanup occurs.