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
