| Oracle FAQ | Your Portal to the Oracle Knowledge Grid | |
 |
 | |||
| Oracle FAQ | Your Portal to the Oracle Knowledge Grid | |
|
| |||
Home -> Community -> Mailing Lists -> Oracle-L -> Re: Wrapping all tables with packages and scalability
Nuno ,
I wonder, what sort of J2EE env was that and specific set of J2EE/JDBC
features caused "a lot of meta-data traffic". And how using stored proc
helped to avoid it?
Personally, I found quite opposite. Weblogic implements both connection
pooling and cursor caching good enough to eliminate parsing (even soft) in
most cases. Of course, no need for metadata when cursor is already persed :)
Stored proc , from the other side, do not let us use batch (array) features,
restricting scalability.
Regarding object types in Oracle - it costs so much CPU on server side,
there is very subtle chance it can be more efficient than doing all fancy
object stuff on application side - where it belongs, and let Oracle do plain
database job. It is much easier to scale application layer than DB.
Cheers
Vadim
> ----- Original Message -----
> From: "Ryan" <ryan.gaffuri_at_cox.net>
> > I'm familiar with abstraction and Object Oriented design. This is
> > essentially what you are talking about. I like it, I am just concerned
> about
> > scalability. If REF Cursor opening and closing has overhead..., then
there
> > is a concern at the very high end. I talked to some guys building an
>
> Akshally, strictly speaking this is not OO design... It's simply
> abstracting
> and wrapping the table itself and its basic operations with a procedural
> ("method")
> wrapper. OO design is a bit more than just that! Hence the difficulty of
> relational-OO mapping.
>
> Scalable? Let's put it this way: I don't know about traditional
> environments
> but with J2EE it's probably the fastest and most efficient way you can
> interface
> to the Java app layer. I've used it extensively in the last 3.5 years and
> it
> has not yet produced any "surprises". There is a lot of meta-data traffic
> that
> takes place in a conventional JDBC access that this technique avoids.
Until
> such
> time as some J2EE idiot decides to "complexify" it...
>
> Interestingly with Forms 9 and 10 you can also specify a set of procedures
> or packages as the "base table" for a block. I've never tried it, but I'm
> sure it would also produce very good results.
>
> Note that this technique does not replace conventional overhead of
parsing.
> If you have to parse, it's still an overhead regardless of the interface.
> What it does is provide a more efficient interface to the Java world with
> JDBC. However, you MUST use the entire range of interface options: if you
> give your procedures the same number of parameters as there are columns
> in the table, then you're hardly gaining anything. You MUST use object
types
> as the procedure interface parameters, where each object type is a row of
> the
> table (or a part thereof).
>
> Cheers
> Nuno Souto
> in sunny Sydney, Australia
> dbvision_at_optusnet.com.au
>
> ----------------------------------------------------------------
> Please see the official ORACLE-L FAQ: http://www.orafaq.com
> ----------------------------------------------------------------
> To unsubscribe send email to: oracle-l-request_at_freelists.org
> put 'unsubscribe' in the subject line.
> --
> Archives are at http://www.freelists.org/archives/oracle-l/
> FAQ is at http://www.freelists.org/help/fom-serve/cache/1.html
> -----------------------------------------------------------------
-- Archives are at http://www.freelists.org/archives/oracle-l/ FAQ is at http://www.freelists.org/help/fom-serve/cache/1.html -----------------------------------------------------------------Received on Mon May 03 2004 - 06:04:12 CDT
 |
 |