We have migrated our forms application from 10.1.2.3 to 184.108.40.206, and since the go-live, we are running in issues. Our users are experiencing freeze (JRE appears not responding). We noticed that when the freeze happen, the users cannot continue their work and close the browser and start a new session.
On the backend (database), we notcied active sessions with Row lock contention.
We are not sure if this issue is a bug in forms 11g or JRE.
Our workstations run XP SP3, IE8, JRE 1.6.0_24
We have seen this issue occur many times in the past with both Forms versions 220.127.116.11 and 18.104.22.168. Do you know if this happens to occur if you are expecting a function such as SHOW_ALERT to be run?
If the freezing is occurring when an alert is trying to be invoked by SHOW_ALERT, you may need to install Oracle patch 12433970 from My Oracle Support to fix the problem. Make sure you review the README file included in the zip before you apply any patch from Oracle as it contains prerequisites and post-installation steps that must be done before and after applying an Oracle patch. For more information, you may review both http://pitss.com/us/2012/07/10/alert-message-or-submit-functions-in-forms-causes-forms-to-freeze/ and Oracle Support note 1171063.1.
If the freezing is still occurring after applying Patchset 12433970 or if the freezing is occurring in areas outside of SHOW_ALERT, there is a workaround which can be applied in both webutiljpi.htm and formsweb.cfg (assuming you are using WebUtil). In webutiljpi.htm, you will need to set up a new parameter called "cache_archive_ex". After that, add this parameter to formsweb.cfg and move all jar files that were originally in the archive parameter (except for frmall.jar) to the new parameter and add ";preload" to the end of each jar file in the cache_archive_ex parameter. After applying this, only frmall.jar should exist in the archive parameter for each application you are using (default, webutil, etc.). For more information, you may review both http://pitss.com/us/2013/02/20/forms-application-freezes-on-alert-functions-even-with-patch-12433970-applied/ and Oracle Support note 1328039.1.
If for any reason that both fixes above still cause freezing issues, check in your database to make sure that there is an index in the foreign key of the child key if it either updates the parent table's primary key, deletes anything from the parent table, or a combination of both. More information can be found in this Oracle Forums post Locking in 11g when migrated from 10g
You may also want to consider upgrading your Forms 11gR2 environment from 22.214.171.124 to 126.96.36.199 as the bugs noted above in both Oracle Support notes 1171063.1 and 1328039.1 are fixed in Forms 188.8.131.52.
i had this same problems years ago.
there are 2 things i did to solve it.
1.- I detected that when my app updated a table that was used for other users (for example a table where i took the next invoice number), and i displayed an alert or message that need to be clicked by the user, then the database wait until the app issue the commit, mean while any other user that was trying to take the next invoice number generated a row lock. so, now i don't display any alerts or messages (without raise) to users after i updated a table like this.
2.- i run a script to create missing index, this was making my app freeze for missing index, ths script name is : TFSFKCHLK.SQL , here is some link: http://www.oracle-wiki.net/startsqlcheckformissingfks
Have you find a solution to this freeze up issue. We are having a similar issue, we have upgrade from 10g to 11g Forms 184.108.40.206. Have applied the Oracle recommended patch but still seeing the freeze up. We have not apply the workaround that suggested after the patch did not resolve the issue. I am also thinking to change Java.exe process affinity to run it on single processor, many people reported that it resolve the freeze up issue.
If you have found solution to this problem, I really appreciate if you can share it with us. I am running out of option now.