Kbase 19089: OPEN CLIENT: Failure to Close Temp-Tables Causes Problems
| Autor |
Progress Software Corporation - Progress |
| Acesso |
Público |
| Publicação |
02/09/1999 |
|
OPEN CLIENT: Failure to Close Temp-Tables Causes Problems
Title: OPEN CLIENT: Failure to Close Temp-Tables Causes Problems
KnowledgeBase Number: 19089
Creation Date: 02-SEP-99
Modified Date:
This document applies to: Progress 9.0A and higher
Version and Release Number: 9.0B
Summary:
When retrieving the contents of an INPUT-OUTPUT or OUTPUT temp-table
it is extremely important that you invoke the close() method against
the temp-table (ResultSet) immediately after you finished retrieving
the data (either all or part of it).
Failure to do this will keep you from issuing further calls to the
AppServer on the same connection. If you configured the AppServer
connection (within your application) to queue multiple requests
for execution instead of returning an error it is quite likely that
your application will appear to hang for no apparent reason.
For those of you using Java as your client it is also important that
you do not put the code to close the resultset in the finalize()
method of any class. This is because Java makes no guarantees about
when the finalize() method will get invoked on an object. Java only
requires that an object be finalized before it is garbage collected.
The book titled "The Java FAQ" by Jonni Kanerva describes the details
regarding the finalize() method as follows:
Objects use system resources, and a well-behaved object should free
its resources for reuse once the object is no longer needed. One
system resource, storage space for objects, is managed automatically
by the Java Virtual Machine: the virtual machine detects when an
object is no longer usable and eventually reclaims the object's space
for use by new objects. If your object uses any other system
resource, such as a graphics context, an open file, or a network
connection, it is up to you to explicitly manage that resource.
Java's system of finalization provides a simple notification service
with which you can define how your objects free up their resources.
The most common confusion about finalization is *when* it occurs.
There is much leeway -- a virtual machine is required only to obey the
following sequence:
1) Your program removes its last reference to an object.
2) The virtual machine invokes finalize() on that object.
3) The virtual machine garbage collects the object.
What this means in practice, such as on the JDK 1.02 and 1.1 virtual
machines, is that finalization waits for garbage collection, and then
runs immediately prior to the actual reclamation of space. You can
wait indefinitely for finalization to occur, because garbage
collection usually waits until either the system runs low on memory
or there is sufficient slack time in the application. If you need to,
you can initiate finalization and garbage collection explicitly by
invoking System.runFinalization() or System.gc(), but these methods
provide no guarantees either. Finalization or garbage collection
(depending on which method you invoke) will occur, but there is no
guarantee that some specific object of yours is ready to be finished
off.
Because the timing of finalization is implementation dependent, and
even circumstance dependent, you can't rely on finalization for
consistent, timely behavior. Wherever possible, you should free
critical system resources explicitly in your code and rely on
finalization as more of a backup measure.