| From: BROKE::BITHER "Please reply to [email protected]" 20-MAY-1997 14:42:49.44
To: M5::MEMORMAN
CC: BITHER
Subj: New STARS article
TITLE: DBI Remote Links Using Database Services
PRODUCT: Distributed Option 7.0
RELATED
PRODUCTS: SQL/Services 7.0
Rdb 7.*
OP/SYS: OpenVMS VAX, OpenVMS AXP
SOURCE: Oracle Worldwide Customer Support
PROBLEM:
Remote link connections (remote database attaches) in Distributed Option (DBI)
do not disconnect when exiting from a SQL/Services database service.
SCENARIO:
A client connects to a SQL/Services database service which is preattached to a
DBI database. The DBI database has links to multiple underlying remote
databases. The user accesses a table in DBI from one of the remote underlying
databases and disconnects. Consequently, an active remote connection still
exists from the DBI server to the remote database.
As more and more users access tables from different underlying remote
databases via DBI and database services, it is possible to activate several
remote connections and have them remain active after users disconnect
from the server. For each different remote link that has been activated
per each database class service an active remote link will remain.
QUESTION:
Is there anyway that remote database attaches can be disconnected when the
user disconnects from the service without losing the benefits of transaction
reusable services?
ANSWER:
This is expected behavior for both transaction reusable database services and
nontransaction reusable database services. In interactive SQL, when a process
attaches to DBI and selects from tables that activate links to underlying
databases those links remain active for the life of the attach. The only way
to deactivate these links is to log out and back into DBI.
When using a transaction reusable database service, processes are using the
same process stream to a particular service and consequently are accessing the
database in the last state it was left in by a previous process (after a commit
or rollback.) If the previous process selected from a table from a remote
underlying database, that link will have been activated. After a
commit/rollback, the session is ready for another user process but the link
will still be active because the service has not logged out of and back into
DBI. This is the nature of a database service. That is, a disconnect from the
database is not done in order to avoid the overhead of attach processing for
other database service users. Commit/rollback will not deactivate links, only
logging out and back in will do this.
When using a nontransaction reusable database service, processes cannot share
a single process accessing the database service (as in the case of
nontransactional services) but they can reuse a process that accesses the
database service. When they do this, that process is preattached to the
database and if any remote links were activated by a previous process using
that process stream those links will still be still be active when the new
process logs on because by nature the database service will not have
disconnected from the database (the only way to deactivate the links.)
Advantage:
----------
Performance should be better in that once the links are activated (attaches to
the underlying databases are made) the overhead of these database attaches
does not need to be incurred again by any other processes for the life of the
connection to the service.
However, if it is necessary for your system to minimize the number of active
remote links the solution would be to use a generic service. That way
each time a user process disconnects from the service the attachment to
the database is also disconnected and this will inactivate the links.
\
\ CONTRIBUTORS:
\
\ Technical: Diane Bither
|