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
