Initial error in call to procedure is cached

Question

Hi,
I'm running Apex 4.1.0.00.32, with Apex Listener 1.1.3.243.11.40 in WebLogic 10.3.3.0.
I've noticed that if I run a procedure (/apex/schema.procedure) and the first call is unsuccessful (because of an error in the procedure or lack of privilege), all later calls will also fail.
Example, create this procedure:
create or replace procedure bug as
begin
htp.p('Hello bug');
end;
Try to run it using the url http://<server>/apex/<schema>.bug
The web page will show just "Not Found". The listener error log will show
HTTP Status Code: 404 Requested url http://<server>/apex/<schema>.bug is not found.
The problem now is lack of grant. So, do a "grant execute on bug to apex_public_user;".
Refresh the web page but "Not Found" persists.
There are now two options:
- change the url to (for instance) http://<server>/apex/<schema>.Bug (ie change case)
- restart the whole weblogic server (stopping the Apex deployment is not possible)
As changing the case of the url is not practical if the application is generating links, a restart is the option left.
Is this "caching" of initial failure the expected behaviour or have I missed some configuration?
I have no caching enabled in the listener.
Kind regards
Tomas Albinsson
Stockholm, Sweden

Answer 1

why would the listener look up metadata for the procedure to call?
Either the user has the correct procedure name and parameter names - the call succeeds.
Or the name or some parameter is wrong - the call fails and is reported to the user.Hi Tomas,
Let me just repeat again that I don't know exactly how the Apex Listener implements its database calls.
My comments are based on my own experiences from writing the Thoth Gateway, which essentially does the same thing as mod_plsql and the Apex Listener, except it is written in .NET and runs on Microsoft IIS. See http://code.google.com/p/thoth-gateway/ for more details.
One reason for caching the procedure metadata is this:
Let's say you have a procedure with a parameter which is a "table of varchar2" (such as the f01, f02, etc. parameters in the "wwv_flow.accept" procedure in Apex). These can accept zero, one or more values, depending on how many times you have repeated that input element name on the HTML page.
So the Listener receives a call for the "wwv_flow.accept" procedure with a single value for the "f01" parameter. Without looking in the data dictionary (see DBA_ARGUMENTS), there is no way the Listener can know that the f01 parameter is actually a "table of varchar2" (and needs to be bound as that datatype when invoking the stored procedure). If the value is bound as a string (plain varchar2) parameter, the procedure call fails.
Now, there are at least two ways to handle this: You can either catch the error, assume it was really a "table of varchar2" parameter, and try again with that; or you can look it up in the data dictionary beforehand to avoid the error. In either case, it's not good for performance to do this for every procedure call.
The Thoth Gateway actually works this way: It first checks whether it has cached metadata for the procedure. If not, it tries to call the procedure based on just the names and values. If this fails, it silently catches the error and then looks up the procedure metadata from the data dictionary to make sure the parameter types are correct. It then calls the procedure again (and hopefully that should be successful). Then the metadata is cached. Which means that any subsequent invocations of the same procedure don't need to go through the same work again.
Looking up (and caching) the metadata also has another benefit: If there are input elements on the HTML page that do not correspond to parameter names in the procedure (perhaps some client-side JS framework added some input fields dynamically), then the procedure call would fail. You can see this in action using mod_plsql and DBMS_EPG (you get an error along the lines of "arguments in form not in procedure..."). However, the Thoth Gateway (and I believe also the Apex Listener) checks the incoming parameter names against the metadata, and just discards any parameter names/values that are not in the procedure.
- Morten
http://ora-00001.blogspot.com
Edited by: mobra on Oct 20, 2011 10:52 AM