Hey all,
- I sent an e-mail detailing how to shut off PreparedStatement caching
in JBoss 2.0-Final. Please see the archives if you're interested. It
will work for JBoss 2.1 as well(minerva beta3?)
- I am re-writing the PreparedStatement caching for minerva. Who
maintains minerva and where is the CVS for it so I can submit it to
them? Is Aaron Mulder the culprit?
Bill
Filip Hanik wrote:
>> Doesn't this defeat the purpose of caching and prepared statements? If you
>> close the prepared statement then the db connection goes away
>> right? So why
>> used a prepared statmenet at all, beacuse it is never really prepared? It
>> seems to me the cache would need to keep at least one of each prepared
>> statement used to be of any value.
>
>
> no, you should not cache statements. If you are using prepared statements,
> it is on the level of the driver to make sure that they are cached.
>
> a prepared statement should give you the same performance even if you close
> them in your code, since it is handled by the driver, not by the programmer,
> or by jboss.
>
> caching statements goes back to 1997 when the drivers did not do this for
> you. now a days, almost all of them do.
>
> Filip
>
> ~
> Namaste - I bow to the divine in you
> ~
> Filip Hanik
> Software Architect
> [EMAIL PROTECTED]
> www.filip.net
>
>> -----Original Message-----
>> From: [EMAIL PROTECTED]
>> [mailto:[EMAIL PROTECTED]]On Behalf Of Hansen,
>> Richard
>> Sent: Thursday, March 22, 2001 1:53 PM
>> To: '[EMAIL PROTECTED]'
>> Subject: RE: [JBoss-user] A little BMP philosophy/understanding
>>
>>
>> Rick Hansen
>>
>> -----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: [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
>>
>> _______________________________________________
>> 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
>
>
>
_______________________________________________
JBoss-user mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/jboss-user
