Comments on: Here is How to Unpersist Your Persistent PL/SQL Package Data http://awads.net/wp/2007/04/04/here-is-how-to-unpersist-your-persistent-plsql-package-data/ News, views, tips and tricks on Oracle and other fun stuff Thu, 17 Jun 2010 03:52:30 +0000 hourly 1 http://wordpress.org/?v=3.0 By: rohan http://awads.net/wp/2007/04/04/here-is-how-to-unpersist-your-persistent-plsql-package-data/comment-page-1/#comment-52017 rohan Fri, 07 Mar 2008 09:02:19 +0000 http://awads.net/wp/2007/04/04/here-is-how-to-unpersist-your-persistent-plsql-package-data/#comment-52017 <p>my question to Barut - i need your help regarding package level variables. I have 1 package lets say package A that calls package B in a loop passing parameters to a stored proc in package B. Package B has package level variable as a table type (as in the example). The requirement is to persist the data being written into the table type between subsequent calls and hence I've used the package level variable.</p> <p>However the package B keeps on getting uncompiled on its own throwing the error message - "ORA-04068: existing state of packages has been discarded". How do I resolve this issue with the statement - “DBMS_SESSION.MODIFY_PACKAGE_STATE(DBMS_SESSION.REINITIALIZE);” and at same time sticking to the requirement of persisting the data</p> my question to Barut – i need your help regarding package level variables. I have 1 package lets say package A that calls package B in a loop passing parameters to a stored proc in package B. Package B has package level variable as a table type (as in the example). The requirement is to persist the data being written into the table type between subsequent calls and hence I’ve used the package level variable.

However the package B keeps on getting uncompiled on its own throwing the error message – “ORA-04068: existing state of packages has been discarded”. How do I resolve this issue with the statement – “DBMS_SESSION.MODIFY_PACKAGE_STATE(DBMS_SESSION.REINITIALIZE);” and at same time sticking to the requirement of persisting the data

]]> By: GurpreetSingh Tuteja http://awads.net/wp/2007/04/04/here-is-how-to-unpersist-your-persistent-plsql-package-data/comment-page-1/#comment-51321 GurpreetSingh Tuteja Tue, 24 Jul 2007 23:35:05 +0000 http://awads.net/wp/2007/04/04/here-is-how-to-unpersist-your-persistent-plsql-package-data/#comment-51321 <p>Hi, In the above example of SERIALLY_REUSABLE pragma if i type command 'exec my_pkg.do_it; my_pkg.do_it' the answer is for i is 2. I am calling a package twice from another package. The first time all the global variables are reset. But the second the old values still persist. Can you help me??</p> Hi, In the above example of SERIALLY_REUSABLE pragma if i type command ‘exec my_pkg.do_it; my_pkg.do_it’ the answer is for i is 2. I am calling a package twice from another package. The first time all the global variables are reset. But the second the old values still persist. Can you help me??

]]> By: andrew http://awads.net/wp/2007/04/04/here-is-how-to-unpersist-your-persistent-plsql-package-data/comment-page-1/#comment-50482 andrew Thu, 05 Apr 2007 17:19:01 +0000 http://awads.net/wp/2007/04/04/here-is-how-to-unpersist-your-persistent-plsql-package-data/#comment-50482 <p>Out of interest , Oracle 9iAS (unsure about V10), uses dbms_session.reset_package in mod_plsql by default. This is easily visible in the shared pool or a trace file (or by reading the docs...) http://www.sharemation.com/~dmcmahon/modowa.htm</p> Out of interest , Oracle 9iAS (unsure about V10), uses dbms_session.reset_package in mod_plsql by default. This is easily visible in the shared pool or a trace file (or by reading the docs…) http://www.sharemation.com/~dmcmahon/modowa.htm

]]> By: PaweÅ‚ Barut http://awads.net/wp/2007/04/04/here-is-how-to-unpersist-your-persistent-plsql-package-data/comment-page-1/#comment-50480 PaweÅ‚ Barut Thu, 05 Apr 2007 07:29:45 +0000 http://awads.net/wp/2007/04/04/here-is-how-to-unpersist-your-persistent-plsql-package-data/#comment-50480 <p>Eddie, To avoid "ORA-04068: existing state of packages has been discarded" I use "DBMS_SESSION.MODIFY_PACKAGE_STATE(DBMS_SESSION.REINITIALIZE);". It is especially important when you use connection pooling. Always when I get connection from pool, first operation I run is is DBMS_SESSION.MODIFY_PACKAGE_STATE(DBMS_SESSION.REINITIALIZE);. It reinitializes package variables, so you have clear environment. Overhead of calling DBMS_SESSION.MODIFY_PACKAGE_STATE is minimal, ant it simplifies your development. For example I do not have to restart web server every time I change something in packages. Change is visible at once and I do not get ORA-04068 error. Regards, PaweÅ‚</p> Eddie, To avoid “ORA-04068: existing state of packages has been discarded” I use “DBMS_SESSION.MODIFY_PACKAGE_STATE(DBMS_SESSION.REINITIALIZE);”. It is especially important when you use connection pooling. Always when I get connection from pool, first operation I run is is DBMS_SESSION.MODIFY_PACKAGE_STATE(DBMS_SESSION.REINITIALIZE);. It reinitializes package variables, so you have clear environment. Overhead of calling DBMS_SESSION.MODIFY_PACKAGE_STATE is minimal, ant it simplifies your development. For example I do not have to restart web server every time I change something in packages. Change is visible at once and I do not get ORA-04068 error. Regards, PaweÅ‚

]]> By: Eddie Awad http://awads.net/wp/2007/04/04/here-is-how-to-unpersist-your-persistent-plsql-package-data/comment-page-1/#comment-50479 Eddie Awad Thu, 05 Apr 2007 04:45:31 +0000 http://awads.net/wp/2007/04/04/here-is-how-to-unpersist-your-persistent-plsql-package-data/#comment-50479 <p>Patrick, here is the scenario that we had and was actually the trigger for this post. There is one package that has many procedures/functions accessing the same associative arrays declared as private global package data. The data in the associative arrays is massaged and copied over to a procedure output parameters. Then, we have a ColdFusion web application that calls that procedure in the package more than one time. in subsequent calls, new records are added, <em>instead of recreated</em>, to the the data (ref cursor) returned by the procedure. This is not what we want. So, we used SERIALLY_REUSABLE to solve this situation.</p> <p>Moreover, from the documentation: This SERIALLY_REUSABLE pragma is appropriate for packages that declare large temporary work areas that are used once and not needed during subsequent database calls in the same session.</p> <p>You're right about the "i" variable, it can be declared local to the procedure instead of global to the package. In fact, I could have declared g_tab local as well, however, this was a very simple example to specifically demonstrate package data persistency when variables are declared as package globals.</p> <p>Gary, thanks for the clarification. I noticed a strange behavior testing the "alter package ... compile" command on my XE database. I opened two SQLPlus sessions. I then called my_pkg.do_it in session1 and session2 multiple times. The data persisted across calls as expected in both sessions. I then issued "alter package my_pkg compile;" in session1. The package data in session1 was reinitialized, but not in sesion2. When I issued "alter package my_pkg compile;" for *the second time* in session1, I got "ORA-04068: existing state of packages has been discarded" when I called my_pkg.do_it in session2 and only then the package data was reinitialized in session2. Hum!</p> Patrick, here is the scenario that we had and was actually the trigger for this post. There is one package that has many procedures/functions accessing the same associative arrays declared as private global package data. The data in the associative arrays is massaged and copied over to a procedure output parameters. Then, we have a ColdFusion web application that calls that procedure in the package more than one time. in subsequent calls, new records are added, instead of recreated, to the the data (ref cursor) returned by the procedure. This is not what we want. So, we used SERIALLY_REUSABLE to solve this situation.

Moreover, from the documentation: This SERIALLY_REUSABLE pragma is appropriate for packages that declare large temporary work areas that are used once and not needed during subsequent database calls in the same session.

You’re right about the “i” variable, it can be declared local to the procedure instead of global to the package. In fact, I could have declared g_tab local as well, however, this was a very simple example to specifically demonstrate package data persistency when variables are declared as package globals.

Gary, thanks for the clarification. I noticed a strange behavior testing the “alter package … compile” command on my XE database. I opened two SQLPlus sessions. I then called my_pkg.do_it in session1 and session2 multiple times. The data persisted across calls as expected in both sessions. I then issued “alter package my_pkg compile;” in session1. The package data in session1 was reinitialized, but not in sesion2. When I issued “alter package my_pkg compile;” for *the second time* in session1, I got “ORA-04068: existing state of packages has been discarded” when I called my_pkg.do_it in session2 and only then the package data was reinitialized in session2. Hum!

]]> By: Gary http://awads.net/wp/2007/04/04/here-is-how-to-unpersist-your-persistent-plsql-package-data/comment-page-1/#comment-50478 Gary Wed, 04 Apr 2007 22:47:04 +0000 http://awads.net/wp/2007/04/04/here-is-how-to-unpersist-your-persistent-plsql-package-data/#comment-50478 <p>Worth mentioning that "ALTER PACKAGE package name COMPILE" will clear EVERY session's state for that package, not just the one doing the compile. SERIALLY_REUSABLE is a 'quick fix' when you've got a package that uses lots of global variables written by someone who didn't realise about persistance.</p> Worth mentioning that “ALTER PACKAGE package name COMPILE” will clear EVERY session’s state for that package, not just the one doing the compile. SERIALLY_REUSABLE is a ‘quick fix’ when you’ve got a package that uses lots of global variables written by someone who didn’t realise about persistance.

]]> By: Patrick Wolf http://awads.net/wp/2007/04/04/here-is-how-to-unpersist-your-persistent-plsql-package-data/comment-page-1/#comment-50477 Patrick Wolf Wed, 04 Apr 2007 20:26:30 +0000 http://awads.net/wp/2007/04/04/here-is-how-to-unpersist-your-persistent-plsql-package-data/#comment-50477 <p>Hi,</p> <p>I'm just curios, why should anybody use static package variables and on the other side decide to use SERIALLY_REUSABLE?</p> <p>If I really just want to use them for the call, why not just use local procedure/function variables?</p> <p>Something else I noticed in you example, why don't you declare "i" as local variable, does it really have to be static?</p> <p>Patrick</p> Hi,

I’m just curios, why should anybody use static package variables and on the other side decide to use SERIALLY_REUSABLE?

If I really just want to use them for the call, why not just use local procedure/function variables?

Something else I noticed in you example, why don’t you declare “i” as local variable, does it really have to be static?

Patrick

]]>