| T.R | Title | User | Personal
Name | Date | Lines |
|---|
| 1153.1 | Expected behavior | BROKE::BITHER | | Wed Apr 16 1997 10:51 | 30 |
| Hi Colin,
I believe this is expected behavior. 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. There
is no way that I know of to deactivate the links without logging out of
dbi and back into dbi. You've probably seen this if you've ever tried to
drop a link that has been activated. You can't until you logout and log
back in.
Because you are using a transaction resusable service, processes are using the
same 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 udb, 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. Commit/rollback will not deactivate links, only
logging out and back in will do this.
I don't see how you can do this except by using a database class
service that is non transaction reusable. That way each user process
that uses the service will be preattached to the database but no links
will have been activated because each process will be first-time
user of the session.
However, the upside of this is that performance should be better in that the
overhead of activating the links does not need to be incurred by any other
processes for the life of the service.
Diane
|
| 1153.2 | Take it as a C/E request. | 10245::COBROWN | Colin from Danmark | Thu Apr 24 1997 15:57 | 10 |
| Thanks for the reply.
The problem is they end up with dozens of links and if one of them has
had a network failure the next user gets the error, even if they were
not accessing the failed link:-(
I think the CT is just trying to bring our attention to an issue that
we could address at some time in the future.
Colin
|
| 1153.3 | Wish listed... | BROKE::ABUGOV | | Thu Apr 24 1997 17:18 | 7 |
|
Hi Colin,
We've added it to our ever expanding wish list (this one has
dependencies on both sql and sql services...).
Dan
|
| 1153.4 | problem w/both types of database services | BROKE::BITHER | | Fri Apr 25 1997 13:03 | 19 |
| Hi Colin,
I wanted to add one more thing. What I said in .1:
>I don't see how you can do this except by using a database class
>service that is non transaction reusable. That way each user process
>that uses the service will be preattached to the database but no links
>will have been activated because each process will be first-time
>user of the session.
This is wrong. The same problem exists with non transaction database
services too. Since the service does not disconnect from the database, the
links remain active. The only way the links get dropped is to logout/log back
into dbi and this would only be done when using generic services.
Diane
|
| 1153.5 | Crossposted in SQL/SERVICES 2196 | 10245::COBROWN | Colin from Danmark | Tue Apr 29 1997 09:51 | 8 |
| I have opened a new SQL/services note 2196 as a reasonable partial
solution is to allow the option that a server commits suicide when
there is a network error from a remote link.
This would aviod the problem of all clients hitting a server where an
old link has died getting errors.
Colin
|