From: karsten_schmidt8891@my-deja.com
Newsgroups: comp.lang.java.databases,comp.databases.oracle.misc
Subject: Re: statement caching in oracle
Date: Fri, 02 Feb 2001 08:11:15 GMT
Organization: Deja.com
Lines: 104
Message-ID: <95dq2v$d3k$1@nnrp1.deja.com>
References: <93lfj4$274$1@nnrp1.deja.com> <3A646B19.66A861F8@brokat.de> <959csk$gjr$1@nnrp1.deja.com>
NNTP-Posting-Host: 194.121.39.251
X-Article-Creation-Date: Fri Feb 02 08:11:15 2001 GMT
X-Http-User-Agent: Mozilla/4.72 [en] (X11; I; Linux 2.2.14 i686)
X-Http-Proxy: 1.0 dd-lx-proxy:3128 (Squid/2.3.STABLE4), 1.0 x62.deja.com:80 (Squid/1.1.22) for client 192.168.0.177, 194.121.39.251
X-MyDeja-Info: XMYDJUIDkarsten_schmidt8891


Hi,
 which stats do you you use to get to that conclusion ?
 I am using jdbc/Thin 8.1.6, with no problems. I do not seem to have a
cursor-sharing issue (not that i know of, at least).

 I implemented a client-side lru cache for cursors anyhow, since oracle
connection pooling and clientside cursor caching appear to be mutually
exclusive. I opted to use the built-in connection pool.

When you do that yourself, make sure, you have one cursor cache per
physical connection - otherwise it won't work (how should it ??)

Karsten


In article <959csk$gjr$1@nnrp1.deja.com>,
  Keith D. Gregory <kgregory@tibco.com> wrote:
> Actually, I think there are some caveats here (which is why I'm
> searching this topic). It appears that Oracle _will not_ cache a
> PreparedStatement on the server if you close that statement on
> the client (Thin Driver, 8.1.6). In my test program, the only way
> to get it to cache the statement on the server was to implement a
> client-side cache, which would leave the PreparedStatement object
> open.
>
> If anyone knows a way to allow me to call PreparedStatement.close()
> and still have the server cache the statement -- or even better,
> reuse a statement from another session, please let me know.
>
> -kdg
>
> In article <3A646B19.66A861F8@brokat.de>,
>   Frank Gerlach <Frank.Gerlach@brokat.de> wrote:
> > I suggest to use PreparedStatement only, which will allow Oracle to
 reuse
> > already parsed and optimized statements. Oracle does this by
 creating
 a
> > hash over the statement text (the "SELECT.."), which means it will
 not
 work
> > without a PreparedStatement. I do not think it is a good idea to
 call
> > internal methods of the Oracle jdbc implementation. Use the Oracle
 Server
> > admin tools to change the statement cache size, as the statement
 cache
 is a
> > server-side entity !
> >
> > miso_pach@my-deja.com wrote:
> >
> > > Hi
> > >
> > > In my java program i repetedly call certain queries. I would like
 to
> > > take advantage of a statement cache, so that these queries would
 not
> > > have to be parsed by the database every time and thus improve the
> > > performance.
> > >
> > > I am using the latest JDBC thin driver (8.1.7), which provides
> > > API for setting the size of the clients statemet cache. This works
 fine
> > > with a physical instance of a PooledConnection. However if am
 trying
> > > to use it in combination with OracleConnectionCacheImpl class I
 will
> > > only get access to logical connections which don't let you set
> > > their statement cache. I tried calling
> > >                 setStmtCacheSize()
> > > on the OracleConnectionCacheImpl which didn't work. The prepare
> > > statement on the 2nd connection just hanged. The first connection
 was
> > > bizzarly fine..
> > >
> > > How can I set the statement cache for all connection created by
 the
> > > OracleConnectionCacheImpl class?
> > >
> > > Insted of setting this from the java program I could surly set the
> > > connection cache somehow for the whole database. How do I do that?
> > > This could be a workaround if the oracle's java API doesn't let me
 do
> > > it.
> > >
> > > any responses would be appreciated.
> > >
> > > thanks,
> > >
> > > Miso
> > >
> > > Sent via Deja.com
> > > http://www.deja.com/
> >
> >
>
> Sent via Deja.com
> http://www.deja.com/
>


Sent via Deja.com
http://www.deja.com/