How to execute a function in oracle plsql object, when object dies

Question

I have a plsql object with a member function as exec_last.
I want this procedure to be called when plsql object is cleaned or when the session hosting this object dies.
In C, we have a system call as atexit(). Is there any such feature in Oracle 10g or any workaround using embedded java.
This feature is required to flush the contents stored in plsql table in the object to the database, when program exits.
Thank you,
Warm Regards,
Navin Srivastava

Answer 1

navsriva wrote:
Is there any better way to implement this in memory caching. What is the buffer cache of Oracle? It is exactly that - a memory cache for data blocks. Both new blocks (created by inserting new rows) and existing blocks (used by selects, updates and deletes, and re-used (freespace) by inserts).
The Oracle buffer cache is a very mature and sophisticated cache. Attempting to do it "+better+" than the db buffer cache in another software layer (like PL/SQL) is mostly a waste of time and resources.. and invariable introduces another s/w layer that simply increases the number of moving parts. This in turn usually means increased complexity and slower performance.
Why use bulk processing in PL/SQL? The basic and fundamental answer to that is to decrease the context switching between the PL engine and SQL engine.
When running PL code to insert data into SQL, that data needs to be passed to the SQL engine, the PL engine needs to perform a context switch to the SQL engine to allow it to process that data and perform the SQL instruction.
If there are a 1000 rows to inserts, it means a 1000 context switches.
Bulk processing makes the "+communication/data pipe+" between the two bigger. Instead of passing a single row's data to the SQL engine via a context switch, a bulk collection/array of a 100 rows is passed. There is now a mere 10 context switches required to push that 1000 rows from the PL engine to the SQL engine.
You can do the same from any other SQL client... (remember, that PL itself is also a SQL client). You can, using C/C++ for example, do the exact same thing. When passing row data to the SQL engine to insert, pass a collection of a 100 rows instead of the data for a single row.
The exact same benefits result as in PL/SQL. A bigger communication pipe, allowing more data to be transferred to/from the SQL engine, resulting in less context switching.
Of course, a context switch ito C/C++ is a lot more expensive than in PL/SQL - as the PL engine sits in the very same physical process as the SQL engine. Using C/C++, this will usually be a separate process communicating with the SQL engine process across the network.
The same applies to other languages, like Java, C#, Delphi, Visual Basic and so on.
It does not make sense to introduce another s/w layer, the PL/SQL engine, and have the client "+insert+" rows into its memory structures... and then use the PL engine to "+flush"+ that to the SQL engine via a bulk process command.
It will be faster, and more scalable, having the client language using bulk processing directly and dealing with the SQL engine directly.
Simple example. What does the SQL*Loader program (written in C) use? It does not use PL as a proxy for moving data from a CSV file into a SQL table. It calls SQL directly. It uses bulk processing. It is very fast at loading data.
There is an exception to this. When PL is used as a business processing and validation layer. Instead of the client code implementing that logic, it is done using PL. The client then no longer will manually add an invoice to the INVOICES table for example. It instead calls the AddNewInvoice PL/SQL procedure - and this procedure does all. It checks the customer code as valid. Ensures that there's stock available of the products being ordered on the invoice. Etc.
But in this scenario, PL is not used a secondhand "buffer cache". It is used for what it has been designed for - a proper application layer inside the database.