× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



On 2/13/2013 4:26 PM, James H. H. Lampert wrote:

Would anybody happen to know whether or not it's OK to change the order
of the DeleteLocalRef calls (i.e., do "stmt" before "rs")? This would
allow me to avoid having two identical IF statements, but I fear it
might also create a hidden flaw that might not show up in tests. If I
can help it, I'd rather not send out a product with a memory leak (or
worse)!

Nice sleuthing!

I am a Java dabbler, at best. However, it seems to me that
DeleteLocalRef has been superseded by PushLocalFrame and PopLocalFrame.
http://docs.oracle.com/javase/1.5.0/docs/guide/jni/spec/functions.html#global_local These are implemented in JDBCR4 as jdbc_begin_object_group and jdbc_end_object_group.

However, the 7.1 documentation still refers to DeleteLocalRef.
http://publib.boulder.ibm.com/infocenter/iseries/v7r1m0/index.jsp?topic=%2Frzasc%2Fsc092507243.htm
The example on the next page shows the use of BeginObjectGroup,
reserving FreeLocalRef for the temporary object created during the
attempt to get the JNI environment pointer.

I have no canonical reference as to whether it matters if we delete the
statement reference in a different order to the result set reference.
Intuition tells me it won't matter because we aren't trying to refer to
anything in FreeResults - we're marking them eligible for garbage
collection.

I don't have any production code and thus no anecdotal evidence either.
--buck

As an Amazon Associate we earn from qualifying purchases.

This thread ...

Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.