Abstract lobs increases with every call and not released

Question

Running on 11.2.0.2
We're generating some xml web feeds for our website from relational data using SQL/XML operators. I fetch the xml into a PLSQL CLOB variable using XMLSERIALIZE, which i then return to my java application.
Our site has seen a huge increase in activity and requests to our feeds, and our DBA is reporting we're running out of temp tablespace. We've increased temp tablespace, but he also mentioned that memory consumption is steadily increasing, eventually, DB instance needs to be bounced, otherwise it crashes.
I've discovered that my block of code that builds and returns the xml is causing abstract lobs to increase, but never recedes.
Re-reading the following from 11gr2 Large Objects guide:
Temporary LOBs created in a program block as a result of a SELECT or an assignment are freed automatically at the end of the PL/SQL block or function or procedure. You must also free the temporary LOBs that were created with DBMS_LOB.CREATETEMPORARY to reclaim system resources and temporary tablespace. Do this by calling DBMS_LOB.FREETEMPORARY on the CLOB variable.
Note:
If the SQL statement returns a LOB or a LOB is an OUT parameter for a PL/SQL function or procedure, you must test if it is a temporary LOB, and if it is, then free it after you are done with it.
Also learned the following (as of 10gr2)
A new column named 'ABSTRACT_LOBS' has been added to the V$TEMPORARY_LOBS table. This column displays the number of abstract LOBs accumulated in the current session. Abstract LOBs are temporary lobs returned from queries involving XMLType columns.
so my question is, is my java application responsible for freeing up the LOB? It seems freeing the lob in my PL/SQL function has no effect, since it returns the LOB to JAVA.

Answer 1

Hi Odie,
Calling it with an CallableStatement... packaged function returns a clob.
My DBA is having trouble tracking down the temp lob usage in production it seems. And I question whether my little test case i did in our development environment is actually correct. I tested by calling my packaged function in a sql statement then selecting from v$temporary_lobs. that is where i was seeing abstract_lobs increasing.
Not 100% sure this is what is happening though when calling from an CallableStatement in Java.
That said, I have added some java code to check whether the CLOB returned from my function is temporary, and if so, I free it using the oracle.sql.CLOB implementation. The java code is logging that it is indeed a temporary lob and does free it. I can't confirm though whether this is impacting the temp lob count in the DB, since I believe v$temporary_lobs is based on current session.