× 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.



James,

Java objects are not stored in your RPG program, and they are not kept in activation groups. The RPG variables (that are type O = objects) are not actual objects, they are just numbers that are passed to Java -- they are like "handles", if that helps... just a number that tells Java which object you mean. The object itself is inside the Java virtual machine.

The jdbc_begin_object_group() actually calls an API called PushLocalFrame() that starts a new "frame" in the Java environment. Basically, it's added to a stack. the jdbc_end_object_group() calls a PopLocalFrame() API that removes the top frame from the stack. Every object that's created in between the time the frame is pushed, and the time it's popped, is 'freed' at that time.

I put 'destroyed' in quotes, because that's not completely accurate. Java actually keeps a "reference count" to each object, as many different routines might be referring to it. What this really does is tell Java that your routine is done with it, effectively, reducing the reference count. Java has a background process called "garbage collection" that runs periodically, and will free up any objects that no longer have references to them.

As for jdbc_begin_object_group creating a reference... no... what it does is ask the OS where the JVM is located in memory, since it needs that "JNI Environment" address in order to call the Java Native Invocation APIs. This is not creating an object in the JVM, it's just retrieving the address where the JVM is located in the system's memory. It does not allocate memory or anything, either. Also, it should only do this once... once it has a pointer to the JNI environment, it should just re-use what it has in memory.


Yes, if you call "begin object group" at the start of your program, and "end object group" at the end of your program, it should clean up all of the objects that you create.

ending the activation group will have no effect on the objects, since they are in the JVM, not in your ILE program. Java does not use ILE activation groups.

Ending the job will unload the entire JVM (and therefore all objects that it has allocated.)


On 10/8/2013 12:22 PM, James H. H. Lampert wrote:
Scott Klement said (in my "quick questions" thread):

The object group cleans up everything /except/ the 'rsmd' object. You
still need to clean that up when you're done. (Unless there's an
additional begin/end object group that's taking care of it.)

You can refer to it throughout your program after it has been retrieved
-- UNTIL it gets cleaned up (for example, by ending the object group
it's a part of, or freeing that particular object directly, etc.)

I'm looking at jdbc_begin_object_group in the JDBCR4 source. And it
looks like every time jdbc_begin_object_group gets called, it, in
itself, creates a local reference to the JNI, that never gets explicitly
freed up. Now, I trust Scott's knowledge of calling Java from RPG
implicitly, but I'm having trouble wrapping my mind around some of the
concepts involved.

It's looking like object groups nest. Am I at least getting that part right?

Is my answer then to begin an object group of my own, before I start
opening the JDBC connection, and end it as soon as I've closed the
connection?

And what happens to any un-freed Java objects when the activation group
in which the RPG program runs ends? When the job ends?

--
JHHL


As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:
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.