Session Modes Differences
- Thread starter nanquim
- Start date
patch
Member³
17.3 Session mode
Multi-threading implies that you need a multi-session environment. After all, the Oracle Server can only
execute one statement at a time for any given database session. Things can only run simultaneously if
they run in different sessions. Not all development environments allow for an unlimited amount of
sessions, so that a preference can be set (see chapter 20.2) that controls the amount of sessions that
PL/SQL Developer will use. This preference is called the Session mode, and can have one of the
following values:
Multi session - Each Test Window, SQL Window and Command Window will have its own
session, and another session will be used for compilations. This is the most flexible setting, and
will obviously lead to the largest amount of database sessions. Another possible disadvantage is
that updates in Window X will only be visible in Window Y after they are committed.
Dual session - The Test Windows, SQL Windows and Command Windows belonging to the same
connection will share one session, and another session will be used for compilations.
Disadvantage of this mode is that only one window can execute at a time for a given connection.
Single session - All windows and all compilations for the same connection will use the same
session, making transaction management difficult. The debugger is disabled in this mode. Only
use this setting if you are restricted to using one database session.
Multi-threading implies that you need a multi-session environment. After all, the Oracle Server can only
execute one statement at a time for any given database session. Things can only run simultaneously if
they run in different sessions. Not all development environments allow for an unlimited amount of
sessions, so that a preference can be set (see chapter 20.2) that controls the amount of sessions that
PL/SQL Developer will use. This preference is called the Session mode, and can have one of the
following values:
Multi session - Each Test Window, SQL Window and Command Window will have its own
session, and another session will be used for compilations. This is the most flexible setting, and
will obviously lead to the largest amount of database sessions. Another possible disadvantage is
that updates in Window X will only be visible in Window Y after they are committed.
Dual session - The Test Windows, SQL Windows and Command Windows belonging to the same
connection will share one session, and another session will be used for compilations.
Disadvantage of this mode is that only one window can execute at a time for a given connection.
Single session - All windows and all compilations for the same connection will use the same
session, making transaction management difficult. The debugger is disabled in this mode. Only
use this setting if you are restricted to using one database session.
Last edited:
Personally, I prefer to only use the Dual Session mode.
I prefer one PL/SQL Developer instance to just connect to one database, and to avoid confusions to why one window can't yet see the uncommitted changes from another window.
On the rare occasions when I need to connect to a second database, or to check the progress of a long-running (committing) script, then I open a second PL/SQL Developer on a second monitor. Click your mouse's scroll wheel over the PL/SQL Developer icon on the Windows Toolbar to achieve this.
Hope this helps,
-mobailey
I prefer one PL/SQL Developer instance to just connect to one database, and to avoid confusions to why one window can't yet see the uncommitted changes from another window.
On the rare occasions when I need to connect to a second database, or to check the progress of a long-running (committing) script, then I open a second PL/SQL Developer on a second monitor. Click your mouse's scroll wheel over the PL/SQL Developer icon on the Windows Toolbar to achieve this.
Hope this helps,
-mobailey
Last edited:
