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).
>
>
> _______________________________________________
> 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
