This content has been marked as final. Show 2 replies
Each Forms runtime (frmweb) session is unique to each user session. Its access to the queue is unrelated to any other runtime process except the one hosting the form for your unique session. In other words, Forms runtime process 1 is responsible for user session1 only. It is this same proc that will be communicating with the db to collect queried data or AQ information, or any other db info for this session.
More details can be found here:
If you don't find answers to your questions in this doc reference, please explain what exactly you are trying to troubleshoot or understand.
Thank you for your answer, Michael.
I just wanted do be sure not to double the number of DB-Sessions simply by using database events in a form. I imagined a model where a dequeue call was spawned during the whole lifetime of a runform session (or the form beeing active, depending on the scope attribute of the event object). But your answer and the one paragraph in the documentation
The queue is checked for messages once there are no more current operations to be performed
make clear that this is not the case. I now think, a dequeue call is started when a runform session is idle, and aborted when there is an operation to be executed by forms.