On Thu, 22 Mar 2001, Alexander Kogan wrote:
> Hello,
>
> I've been trying to follow this interesting discussion, but
> now I'm lost. Let me explain my confusion:
>
> Usually in my BMP business methods I obtain a connection,
> create prepared statements and close statements and the connection
> at the very end of the method (assuming that jboss is caching
> the connection and statements).
>
> Is that the right pattern?
Usually this is done in ejbCreate, ejbFindByXXX, ejbLoad and ejbStore. Of
course if your business methods are doing additional database access,
that's how to do it.
The point is that you should obtain and close the connection in the same
method (just as you are). We've since gotten into a bit of a tangent about
how JBoss is optimizing things under the covers.
>
> If not, should I open a connection in ejbCreate/ejbPostCreate/ejbActivate
> and close it in ejbRemove/ejbPassivate? Will it speed up the things?
>
> Thanks in advance for any advice.
>
> Alex.
>
>
>
>
> > Mike Jau wrote:
> >
> > So, the caching of the PreparedStatement is stored in the database
> > connection context and is not shared between the database connection. I
> > am thinking a work around way and it may solve the caching issue. If
> > we have the "named connection" from the pool with the lifecyclye
> > control to release the PreparedStatement from the applicaiton which
> > invoke the container specific API, it probably can solve the problem.
> >
> > - Mike Jau
> >
> > -----Original Message-----
> > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
> > Sent: Thursday, March 22, 2001 1:25 PM
> > To: [EMAIL PROTECTED]
> > Subject: RE: [JBoss-user] A little BMP
> > philosophy/understanding
> >
> > 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: To:
> > [EMAIL PROTECTED] "'[EMAIL PROTECTED]'"
> > <[EMAIL PROTECTED]>
> > 03/22/2001 12:42 PM cc:
> > Please respond to jboss-user 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
