I just wanted to clarify one thing about prepared
statements and whether they are cached in jdbc driver,
database or whether automatic or not.
Prepared statements or any other regular statement for
that sake will be cached by the database (Oracle,
MSSqlServer, Sybase, Informix etc) once they are
parsed, validated, compiled. Even if the statement is
not prepared, it is still cashed and will be used by
the database if the statement is exactly the same, i.e
select id, name from mytable is equal to
select id, name from mytable
however is not equal to
select id,name from my table (too many spaces)
therefore, the server has to
reparse,revalidate,recompile.
So, cashing in db pool is automaticly done for
prepared statement and regular statements, and as long
as they are used, they will pretty much will stay
there, however if the pool gets fragmented, and needs
space, ofcourse even the prepared statements will be
flushed out.
Ofcourse this is the beauty of stored procs which can
be pinned if they are frequently being used and will
always be cashed and not flushed out unless
specifically done so by a dba.
so, it is the server which takes care of all this, not
the driver really.
--- Bill Burke <[EMAIL PROTECTED]> wrote:
>
>
> > -----Original Message-----
> > From:
> [EMAIL PROTECTED]
> >
>
[mailto:[EMAIL PROTECTED]]On
> Behalf Of Jay
> > Walters
> > Sent: Monday, May 07, 2001 4:43 PM
> > To: '[EMAIL PROTECTED]'
> > Subject: RE: [JBoss-dev] TODO: JBossCMP 1.1 FAST!
> >
> >
> > We've been down this path before. It is clearly
> not advisable to be
> > updating the primary keys of CMP objects, I
> consider that a JAWS problem
> > rather than a good feature. There are many people
> who consider the change
> > of primary key to be cool, unfortunately for them
> (and good for
> > us) EJB 2.0
> > CMP currently states that you cannot change the
> primary key of a
> > CMP entity
> > bean. This is not enforcable within the EJB 1.1
> specification so I'm not
> > sure what the answer is here, maybe an option in
> jaws.xml to let
> > one disable
> > update of primary key with the promise to be
> good...
> >
>
> The point I'm trying to make is that with CMPs
> current state, we should not
> be encouraging people to have tuned-updates turned
> off because they will
> most certainly run into deadlock problems if they
> have more than one
> concurrent user.
>
> > Oracle caches prepared statements in the kernel of
> the database and their
> > execution is dramatically more efficient than the
> execution of simple
> > statements. This is true across all Oracle APIs,
> sql*plus, OCI, Pro*C,
> > JDBC... As an Oracle consultant this was one of
> the first things I always
> > checked when a customer had a performance problem.
> They have also added
> > caching of JDBC prepared statements into the
> latest JDBC 8.1.7 driver so
> > there is a need to be able to turn this feature of
> Minerva off.
> >
>
> Does the Oracle database kernel automagically cache
> prepared statements, or
> is this something you have to turn on?
>
> What about the oracle 8.1.7 driver, does it
> implicitly cache prepared
> statements or do you have to explicitly turn this
> on? If not , Minerva will
> need some tweaking because there is currently no
> hooks to do this. Please
> correct me if I'm wrong about Minerva, because I'm
> not 100% sure... TIA.
>
>
> > The crucial nut to understand here is that
> something like 75-85%
> > of the time
> > spent processing a client request is usually spent
> in communications with
> > the database. Changing Minerva to avoid
> allocating a new object, or
> > updating 12 fields instead of 13 fields is like
> putting buckets of water
> > into the ocean to raise the water level. You need
> to melt some icebergs
> > here.
> >
>
> Yeah. That's why I'm hoping Dan implements his
> suggested extension to
> finders so that they select entire rows rather than
> just the primary keys,
> thus avoiding multiple unnecessary reads.
>
> Regards,
> Bill
>
> > Now, for every other database in the world all
> this stuff is different, so
> > it's not like one could lock all this stuff down
> for the way Oracle works.
> >
> > Cheers
> >
> > -----Original Message-----
> > From: Bill Burke [mailto:[EMAIL PROTECTED]]
> > Sent: Monday, May 07, 2001 4:30 PM
> > To: [EMAIL PROTECTED]
> > Subject: RE: [JBoss-dev] TODO: JBossCMP 1.1 FAST!
> >
> >
> > BTW, running with tuned updates off is really,
> really, bad. With tuned
> > updates off, CMP will update your primary keys as
> well. Updating primary
> > keys is a crazy thing to do because the database
> needs to obtain
> > write-locks
> > on any indexes/constraints attached to that
> row/table. This can
> > cause major
> > deadlock problems fairly easily with multiple
> concurrent users. Has the
> > update of primary keys in CMP been removed? I
> know there was some talk
> > about it.
> >
> > Also, if you're using Minerva, Minerva has
> PreparedStatement
> > caching and CMP
> > uses PreparedStatements.
> >
> > Regards,
> > Bill
> >
> > -----Original Message-----
> > From:
> [EMAIL PROTECTED]
> >
>
[mailto:[EMAIL PROTECTED]]On
> Behalf Of Jay
> > Walters
> > Sent: Monday, May 07, 2001 8:06 AM
> > To: 'danch ';
> '[EMAIL PROTECTED] '
> > Subject: RE: [JBoss-dev] TODO: JBossCMP 1.1 FAST!
> >
> >
> > I'm not sure what this Oracle raw thing is, but I
> am pretty sure you don't
> > want to be doing it. Use the indexes on primary
> key it'll be plenty fast.
> >
> > Just make sure tuned updates can be turned off
> since with Oracle it'll
> > probably run faster with tuned updates off because
> the database won't have
> > to be parsing all those odd statements. Of course
> for those people whoses
> > rows are 32K long YMMV. By the way, does it use
> prepared
> > statements either
> > way?
> >
> > Where in the code does this select version thing
> go? Is this just done to
> > see if you've got the right version in cache?
> >
> > Cheers
> >
> > -----Original Message-----
> > From: danch
> > To: [EMAIL PROTECTED]
> > Sent: 5/7/01 1:01 AM
> > Subject: Re: [JBoss-dev] TODO: JBossCMP 1.1 FAST!
> >
> > I was about to tackle the most significant
> performance related problem
> > in JAWS (see the discussion and feature request on
> "CMP and finders:
> > optimized" and "optimize collection finders",
> respectively)
> >
> > I've been building database applications for quite
> a while now (damn
> > near the only thing i've ever done, software-wise)
> and am willing to
> > take this task on.
> >
> > More comments follow in-line.
> >
> > marc fleury wrote:
> >
> > > OK,
> > >
> > > I now believe that I am staring at a simple
> fact. The PERFORMANCE IN
> > > CONTAINERS IS BOLONEY!
> > >
> > > Our container can run in 0.05ms (yes **m**s) and
> still excercise 80 of
> > its
>
=== message truncated ===
__________________________________________________
Do You Yahoo!?
Yahoo! Auctions - buy the things you want at great prices
http://auctions.yahoo.com/
_______________________________________________
Jboss-development mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/jboss-development
