Architecture Advice - XMLTYPE, VPD, PL

Question

Hi, apologies if this is off-topic but wasn't sure which forum to pick for general architecture questions...
I've inherited an existing application architecture that we're struggling to scale beyond about 100 concurrent users on small-scale hardware, and would appreciate any advice.
It is a 3-tier web application, using XMLTYPE (CLOB), VPD and with the vast majority of the business logic and workflow coded in PL/SQL.
We're experiencing that the CLOB-based XMLTYPE columns very quickly eat up all available CPU, and our very complex VPD policies tends to slow tables down about 300% above a few thousand rows. Since the data is directly updated in PL/SQL our middle tier (java) can't cache anything.
The expectation is that this architecture should scale to thousands of concurrent users, with reasonablly large data volumes, on relatively small scale (e.g. 2 or 4 CPU) h/w. Our market cannot really afford/have the expertise to use additional Oracle products such as Grid, Partitioning, RAC etc.
I'm not sure where to start - we've tried tuning individual queries but I think we'll need more than that. We're using the latest edition of 10g RDBMS.

Answer 1

I've used a temporary table the way you propose, and it works pretty well. I override a method of my View Object (executeQuery, I think) to call some PL/SQL to load the temporary table before executing the query. Performance is not quite as good, but isn't a show stopper. My particular application was using a read-only VO, with no underlying Entity Object, but I think you could override an EO method to call some PL/SQL to use data from the temporary table to update the real tables.
I've looked at the original version of Avrom Roy-Faderman's framework extension, but I know he substantially revised it since I looked. It is a cool use of the extensible nature of the ADF BC framework. Avrom has placed the framework in samplecode.oracle.com, and now someone else is leading the project.
This should work well for PL/SQL APIs that have only database native types as parameters to the procedures. But it has the same problems as I mentioned before with PL/SQL records and collections, unless you first make them into database object types with CREATE TYPE.
I have also used the JPublisher interface of JDev. This is pretty neat and it can do the CREATE TYPE commands for you and write conversions to and from PL/SQL types. It also generates A LOT of Java code - the problem with it is that as a code generator it has to generate much more code than you would if you wrote it by hand to handle cases that you know won't occur with your data. And the code it writes can be hard to read and maintain. The classes it writes can be integrated into ADF BC objects, but it still is going to need some hand coding to do the job. Or some people abandon ADF BC, and use these as POJOs which can be made into Data Controls.