I believe that Bill Burke is going through the cache and making this right
at the moment (Bill, you listening in case I'm wrong?)
On Thu, 22 Mar 2001 [EMAIL PROTECTED] wrote:
> In the original JBoss 2.0 version the PreparedStatement cache was not
> discarded after the connection was returned to the pool because more than
> likely you might want to issue that one of these PreparedStatements again.
> To make matters worse there wasn't an upper limit on the number of
> PreparedStatement objects in the cache so things would continue to grow as
> you prepared new SQL statements. If you happened to prepare the same exact
> SQL statement then you received the previously cached PreparedStatement
> object but otherwise you got a new PreparedStatement that was also added
> to the cache. This would continue until either a) the database complained
> or b) you ran out of memory which ever came first. On Oracle, for example,
> each PreparedStatement takes memory on the database and once you hit 100
> or so the database throws an exception when you try to get another one.
>
> I patched the code by releasing the PreparedStatement cache when the
> Connection was released and submitted that fix but I'm not sure it was
> accepted. What really needs to happen is that the PreparedStatement cache
> needs to be enhanced so that an upper bound can be established via a
> configuration variable so that after x PreparedStatements have been cached
> new PreparedStatements will push one of the old ones out of the cache.
>
> - Jon Harvie
>
>
>
>
>
> Mike Jau <[EMAIL PROTECTED]>
> Sent by: [EMAIL PROTECTED]
> 03/22/2001 12:42 PM
> Please respond to jboss-user
>
>
> To: "'[EMAIL PROTECTED]'"
><[EMAIL PROTECTED]>
> cc:
> Subject: RE: [JBoss-user] A little BMP philosophy/understanding
>
>
> Could you give me some background information about the Preparedstaement
> caching on the EJB container side?
>
> Since the connection get from pool need to return to pool once the
> transaction done. I assumed that the resouce associate to this connection
> should be released and the released resoure include the preparedstatement.
> Later on, the create preparedstatement will be invoked again from
> different
> connection. How the preparedstatement cached is my question?
>
>
> - Mike
>
> -----Original Message-----
> From: Bill Burke [mailto:[EMAIL PROTECTED]]
> Sent: Thursday, March 22, 2001 12:10 PM
> To: [EMAIL PROTECTED]
> Subject: Re: [JBoss-user] A little BMP philosophy/understanding
>
>
>
>
> Dan Christopherson wrote:
>
> > On Fri, 23 Mar 2001, Peter Routtier-Wone wrote:
> >
> >>> Someone from this discussion group indicate that container might cache
> the
> >>> PreparedStatement.
> >>
> >> I can't speak with authority on this, but that rings true. I'm guessing
> that
> >> interception doesn't happen for the setEntityContext() method and
> therefore
> >> you actually create a PreparedStatement rather than receiving one from
> the
> >> pool.
> >>
> >>> Just for kicks, I gave it a try but transactions weren't completed and
> >>> they'd just hang out there forever, blocking every other persistence
> and
> >>> finder method until they timed out.
> >>
> >> That would bollox lifecycle management, and the described behaviour
> wouldn't
> >> be at all surprising.
> >
> > This is also a common bean bug: 'close()' should be called on every
> > resultset, statement, and connection in a finally clause so that you
> know
> > it happens every time.
> >
> >> On the other hand, I'd have thought that PreparedStatements would be
> far
> >> less costly to manufacture than Connections, and therefore not worth
> the
> >> overhead of managing a pool. I think I'll poke my nose into the source
> and
> >> see what's there.
> >
> > There's often communication with the database to create the
> > PreparedStatement. That way it can pre-compile a query plan. There is a
> > prepared statement cache in JBoss: in JBoss 2.0, it caused problems with
> > Oracle's cursor limit (fixed in 2.1).
>
>
> I'm re-writing the minerva PreparedStatement caching so it handles
> cursor limit better. I'll submit the code tomorrow after I test it.
>
> Bill
>
>
>
> _______________________________________________
> JBoss-user mailing list
> [EMAIL PROTECTED]
> http://lists.sourceforge.net/lists/listinfo/jboss-user
>
> _______________________________________________
> JBoss-user mailing list
> [EMAIL PROTECTED]
> http://lists.sourceforge.net/lists/listinfo/jboss-user
>
>
>
--
Dan Christopherson (danch)
nVisia Technical Architect (www.nvisia.com)
Opinions expressed are mine and do not neccessarily reflect any
position or opinion of nVISIA.
---------------------------------------------------------------------------
If you're a capitalist and you have the best goods and they're
free, you don't have to proselytize, you just have to wait.
-Eben Moglen
_______________________________________________
JBoss-user mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/jboss-user
