Lifetime of Object in the Object Cache on selects

Question

On inserting an object (corresponding to user-defined SQL type), I can use a stack-allocated struct for the object and its indicator structure, and pass these addresses to OCIBindObject.
But on selecting an object (by value, not ref), the doc says one must let the OCI runtime allocate the object struct and its indicator struct in the Object Cache, and call OCIObjectFree when done with the object. But it's unclear whether one needs to free the object for each row of the result set processed, or only once all rows have been processed.
By looking at the cache-allocated addresses of the object/indicator structs, it looks like the same "instance" in the cache is re-used for every row (addresses remain the same for every row). This tends to indicate the same object is reused, as opposed to a new one being allocated. I added a single OCIObjectFree after processing all rows, and things look OK... (read no crash, no complain/error from OCI).
But I feel a little uneasy about this, because unlike in my case, when the object has secondary allocations associated to it (because the type contains strings, collections, or other objects members), if somehow I need to OCIObjectFree for each row, and I don't, then I'm leaking all the secondary storage from previous instances of the object.
Can someone please shed some light on the subject? I find the OCI doc often a little sketchy on these very important lifetime issues. I'd appreciate some advice from someone with Object-Relational aspects of OCI.
Thanks, --DD                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                       

Answer 1

when I have to select objects by value :
* I let oci allocate objects in the object fetch arrayI don't think we have a choice here in fact. At least the way I interpret the doc.
* I have different addresses for every entry in the array after the fetchBut even an array fetch is done is a loop. You fetch 10 rows at a time, and you get say 25, so you have 3 iterations / fetches.
Of course the 10 object entries of a given fetch are different, but is the address of the 6th object the same in the first, second, and third fetch?
* I call OCIObjectFree() for every entry of the
array.If I have retreived object based attributes
from the object, i call OCIObjectFree() on the
object attributes recursively.To made it easier to understand my question, please find below the pseudo-code of what I'm doing (all error checking and most boiler plate arguments OCI requires are omitted, to concentrate on the control flow and the calls made)
create type point_typ as object (
  x binary_float, y binary_float, z binary_float
create table point_typ_tab (
  id number, point point_typ
struct point_typ { // C-struct matching SQL User Type
    float x, y, z;
struct point_ind { // indicator structure for point_typ
    OCIInd self, x, y, z;
static void select_objects() {
    Environment env(OCI_OBJECT);
    env.connect(zusername, zpassword, zdatabase);
    OCIHandleAlloc(OCI_HTYPE_STMT);
    OCIStmtPrepare("SELECT id, point FROM point_typ_tab");
    ub4 id = 0; OCIDefine* define_id = 0;
    OCIDefineByPos(&define_id, 1, &id, sizeof(id), SQLT_UIN);
    OCIDefine* define_pt = 0;
    OCIDefineByPos(&define_pt, 2, 0, sizeof(point_typ), SQLT_NTY)
    OCIType* point_typ_tdo = 0;
    OCITypeByName("POINT_TYP", OCI_DURATION_SESSION,
        OCI_TYPEGET_ALL, &point_typ_tdo);
    point_typ* p_pt = 0;     ub4 pt_size = 0;
    point_ind* p_pt_ind = 0; ub4 pt_ind_size = (ub4)sizeof(point_ind);
    OCIDefineObject(define_pt, point_typ_tdo,
        (void**)&p_pt, &pt_size, (void**)&p_pt_ind, &pt_ind_size);
    sword rc = OCIStmtExecute(0/*row*/);
    while (OCIStmtFetch2((ub4)1/*row*/, OCI_FETCH_NEXT) has data) {
        if (p_pt_ind->self == OCI_IND_NOTNULL) {
            // Use p_pt. Value of p_pt same for all iteration
    OCIObjectFree(p_pt);
    OCIHandleFree(OCI_HTYPE_STMT);
}As you can see, I do a single OCIObjectFree after the loop, and as mentioned previously, p_pt's value (a point_typ address) remains identical during the iteration, but the values in that memory chunk do change to reflect the various point instances (so each point instance overlays the previous one).
Are you saying I should be calling OCIObjectFree(p_pt); inside the loop itself?
And if so, should I call OCIObjectFree(p_pt); even if the indicator tells me the point is atomically null?
That what I do in OCILIB, and it doesn't seem to leak.Reading your post, I'm unsure you free of points in the array after the loop, or inside the loop. I hope the pseudo-code I posted above help to clarify my question.
BTW, OCCI is just a wrapper around OCI. Because OCCI
first releases were buggy (it's getting better) and
just few compilers (and compilers versions) are
supported, OCI remains a portable and workable
solution for dealing with Oracle ObjectsAs I wrote in a separate reply in this thread, I also agree OCI is the way to go, for various reasons.
Thanks for the post. I'd appreciate if you could confirm or not whether what I'm doing is consistent with what you are doing in OCILIB, now that I'm hopefully made my question clearer.
Thanks, --DD