Karam,
i am quite sure you should close the connection. This returns the
connection back to the pool, otherwise the connection can not be
reused by the pool (which makes the pool useless).
I did not follow the "pooldevelopment" the last years, but I think
some pool implementations allow to specify "non-usage-timeouts",
which I think will return the connection to the pool after a certain
time that it has not being used, but in my opinion this can lead to
even harder to debug connection problems. (using a already
automatically repooled connection is probably a bad thing.)
So a managed-bean which has a @PreDestroy method (and possibly even
injection of a datasource per @Resource), or a servletfilter/
phaselistener might be a good solution.
As I have written, its a long time I have "learned" about this, so it
might as well be wrong :)
Imre (qoob)
Ken Paulsen wrote:
>
> Yep, I think so. As long as it correctly maintains the connection
> to the database.
>
> Ken
>
> Karam Singh Badesha wrote:
>> Ken,
>> If I have a java file which holds the connection object, using the
>> same
>> idea I can just pass that java object around and call the methods on
>> that to get data, right?
>>
>> thanks
>> Karam
>>
>> Ken Paulsen wrote On 02/21/07 11:28,:
>>
>>> So instead of each handler getting the connection individually,
>>> pass the
>>> connection in as a parameter. You can initialize a request scoped
>>> variable w/ the connection to use at the beginning of each page that
>>> needs access to it.
>>>
>>> So at the top of your page:
>>>
>>> <!initPage
>>> getOracleConnection(inputA="whatever", inputB="#{whatever}",
>>> theConnection=>$attribute{connection});
>>> />
>>>
>>> When ever you have a handler that needs to query the DB:
>>>
>>> <!someevent
>>> yourHandler(connection="#{connection}" otherParam="..." ...);
>>> ...
>>> />
>>>
>>> Does this make sense?
>>>
>>> Ken
>>>
>>> Karam Singh Badesha wrote:
>>>
>>>
>>>> Imre/Ken,
>>>> Some kind of sample code flow will help. Also we will be using
>>>> the JDBC
>>>> connection pool resource defined in the appserver itself which I
>>>> don't
>>>> think needs closing. And this resource is accessed using JNDI
>>>> classes.
>>>>
>>>> thanks
>>>> Karam
>>>>
>>>> Ken Paulsen wrote On 02/21/07 11:01,:
>>>>
>>>>
>>>>
>>>>> Thanks Imre for the suggestions. These sound like great
>>>>> strategies for
>>>>> doing this.
>>>>>
>>>>> As for JSFTemplating... these approaches should work just fine,
>>>>> JSFTemplating adds an event that could allow you to do similar
>>>>> code at a
>>>>> page-level (initPage) but doesn't have an "afterPage" currently so
>>>>> cleaning up the connection isn't as straight foward (Imre's
>>>>> approach is
>>>>> better).
>>>>>
>>>>> I think I'd follow Imre's suggestions unless you're willing to
>>>>> use EJB3
>>>>> which I think probably manages things for even better.
>>>>>
>>>>> Ken
>>>>>
>>>>> Imre Oßwald wrote:
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>> Hi Karam,
>>>>>>
>>>>>> I don't know, if the question has already been answered?
>>>>>> I would suggest to either put the connection into a thread-
>>>>>> local var,
>>>>>> or probably better - as you are using faces - create a managed-
>>>>>> bean
>>>>>> with request-scope. Then you get the added benefit of the
>>>>>> "Lifecycle"
>>>>>> Annotations: @PostConstruct and @PreDestroy where you could
>>>>>> handle the
>>>>>> (dis-)connecting in a clean way.
>>>>>> To access this bean you can inject it into other request-
>>>>>> scoped-beans
>>>>>> or request it from the facescontext. I would not inject it into
>>>>>> session-scoped beans, as the connection would probably stay
>>>>>> open for
>>>>>> to long, but it depends on your requirements.
>>>>>> These suggestions are without knowing enough/anything about
>>>>>> jsftemplating, so perhaps there is a better-way=the
>>>>>> jsftemplating-way
>>>>>> (Maybe Ken can refine my suggestions)
>>>>>>
>>>>>> Imre
>>>>>>
>>>>>> Ken Paulsen wrote:Am 18.02.2007 um 04:47 schrieb Ken Paulsen:
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>> Hi Karam,
>>>>>>>
>>>>>>> Yes, it's probably a good idea. :)
>>>>>>>
>>>>>>> Unfortunately I'm not an expert in this area. Since you're using
>>>>>>> GlassFish, which is a Java EE 5 container... you have access
>>>>>>> to EJB
>>>>>>> 3. It's annotations make it easy to use. There are a number
>>>>>>> of other
>>>>>>> approaches people take. I'm curious to know what you decide
>>>>>>> to do...
>>>>>>> but I'm not the best person to tell you what approach is
>>>>>>> best. Others
>>>>>>> on this list are likely to have more experience than me.
>>>>>>>
>>>>>>> If you don't get an answer, post a question on the JSF forum,
>>>>>>> or do
>>>>>>> some Google searches to see what people recommend.
>>>>>>>
>>>>>>> Ken
>>>>>>>
>>>>>>> Karam Singh Badesha wrote:
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>> Hi,
>>>>>>>> I have setup a jdbc resource in the appserver for oracle.
>>>>>>>> Now I want
>>>>>>>> to use this from the handlers. Currently each function in my
>>>>>>>> handler
>>>>>>>> connects to the database and then execute the query. But I am
>>>>>>>> wondering if there is a way to avoid this reconnection for
>>>>>>>> every
>>>>>>>> handler call?
>>>>>>>>
>>>>>>>> thanks
>>>>>>>> Karam
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>
>>>>
>>