RE: Srpersist

["Paul A. Steckler" <steck@cs.rice.edu>]

>I have a question about Srpersist:
>
>does the garbage collection in mzscheme take care of freeing handles,
>buffers, indicators?
>
>Or is it advisable to register a handle with a will excutioner which
>frees the handle when it becomes unreachable?

I'd say that, in general, it's not advisable to free ODBC handles through 
a will executor.  

The reason is that some ODBC calls implicitly free them, and there's
no way to query their status.  For example, 'disconnect' frees statement
and descriptor handles.  Further, ODBC drivers tend to be 
unforgiving when handles are freed more than once -- in other words,
they crash.  So if your program explicitly calls 'disconnect', and 
subsequently a will executor calls 'free-handle', you have trouble.

Now, if you carefully set up your program so that the only handle
deallocations take place in the will executor, then you're OK.
But remember, PLT Scheme uses a conservative collector, so the
will executor may never be called.

When/if we build a functional layer on top of SrPersist, handles should 
not be visible, so handle deallocation issues will become invisible.  

Buffers and indicators are allocated using uncollectable memory, because
ODBC may use them, even if there are no Scheme references to them.
For example, you can call 'set-desc-field' with an argument of
'sql-desc-indicator-ptr and an indicator; similarly for
'sql-desc-data-ptr and a buffer.  Even more important is the 
fundamental ODBC notion of binding buffers to columns.  
Once a buffer is bound to a column, it should not be freed. 
Otherwise, a 'fetch' is likely to cause a crash.

Again, I'd expect allocation issues for buffers and indicators 
to become invisible with a functional layer.

-- Paul

 ----------------------------------------------------------------
| Paul Steckler              |     Rice University PLT           | 
| steck@cs.rice.edu          |     DrScheme Project              |
| Tel:  713/348-3814         |     http://www.cs.rice.edu/~steck |
| FAX:  713/348-5930         |     *** Ad astra per hackera ***  |
 ----------------------------------------------------------------