Edition Based Redefinition is nice but...
A reader, June 09, 2011 - 11:47 am UTC
Edition Based Redefinition is nice but in its current state is not very useful for a number of reasons.
1. What about the rest of your application? Your JSP's, Forms, etc. They also use the database. Having to introduce EBR into existing applications can certainly be done but requires additional time and making a PL/SQL implementation change via EBR only adds complexity.
2. EBR Requires a "downtime" for application users to switch to the new edition. They must log off or wait for a new connection in the pool to create a session using the new default edition. Really depends on the other parts (non-db) of your application. Certainly can be done though. But why do it when stateless PL/SQL works?
3. There are non-editionable database objects. I'm sure Oracle is working on this though.
Thank you very much for checking whether or not there is metadata in the database that tracks whether or not a PL/SQL package maintains state. That's what I wanted to know.
Thanks again,
Jason
June 09, 2011 - 12:17 pm UTC
1) what about them - for this user here - the one that wants to update database code while the database is up and running - they'd be doing that anyway.
Patching - fixing a view, a grant, a bug in a package, a broken trigger, etc - can be done online in the database now. We are not trying to fix your stuff outside of the database - that is up to that environment to do that.
2) not necessarily. As always - it depends - and in this case - it wouldn't incur downtime. We can have it so that existing sessions use the existing packages and their state - new session use the newly patched package and its new state. When no one is using the old stuff - there you go, you can drop the old edition.
If you can be stateless - by all means DO SO. I'm not a fan of global variables personally. But, also, read the above request - they have stateful code, they did it on purpose, so we have to deal with it.
3) probably not - that would include tables for example. That's a big big big problem. We have a set of tools that allow you to successfully program an online upgrade with these 'non-editionable' items - things like invisible indexes, editioning view, true online index creates, cross edition triggers, etc etc etc. If you check out the 3 part article - I do go through all of that.
Jason, June 09, 2011 - 1:58 pm UTC
"If you can be stateless - by all means DO SO. I'm not a fan of global variables personally. But, also, read the above request - they have stateful code, they did it on purpose, so we have to deal with it."
Actually, I wrote the original question and that review so I am one of those who wrote it "on purpose". However, I'd like to clean it up. Hence, my question about identifying PL/SQL packages that maintain state by querying the metadata. And I understand it has been answered.
Thanks again,
Jason
Related question
A reader, June 09, 2011 - 10:03 pm UTC
Can I ask a sort of philosophical question here? I am not clear why the error "existing state of packages has been discarded" would have even existed in the first place. If a new version of a package has been deployed to an environment, so what? At least shouldnt there be some way when its built to prevent sessions from throwing the 4061 if I as the developer make the call that I dont care to have current sessions throw the error (without having to code exception blocks for each call to it)?
June 10, 2011 - 7:57 am UTC
Think about this please.
You, the developer, have written a package. It has a variable X in a package - a global. You put into X some bit of data - counting on that bit of data to be there next time you access it.
Now, someone comes along and create or replaced your package body. Your session state has been "lobotomized" at that point - the package has to be reset (you are running new code, the old code quite simply does not exist).
Do we just silently go on and let you process with X being reset to its default?
Or do we have a responsibility to notify you that your package has been reset - and then let you decide what to do?
I think we have that responsibility. the developer/application decides what to do at this point.
Just like if you replace binaries on a Unix machine, you will get things like "page fault" and the program will crash and burn.
Just like on windows - where by you cannot replace a running binary - it just won't let you.
This is what edition based redefinition lets you "work around". With this new feature - you don't have to overwrite the existing code - we can support multiple versions of the code simultaneously.
As for the last bit - "if i as the developer make the call that i don't care to have..." - then I have to ask - why do you have globals in the first place? If you truly don't care - then why do they exist? It only makes sense to maintain a state if you CARE about the state. If you care not a whit about the state - why does it exist?
So...
Jason, January 03, 2014 - 7:58 pm UTC
Forget state.
Being able to deploy new logic to a live system that hundreds of professionals are running on without first having them stop their work is very valuable. And from what I have seen, PL/SQL provides this ability. One of the few nice things about PL/SQL in my opinion.
Again, there is no state.
So, how do you find those PL/SQL packages without state.
Thanks,
Jason
Andy, April 08, 2022 - 12:50 pm UTC
looks like Tom's links are broken. Would be nice to see the articles he has linked here.