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
>>>>>>
>>>>>>
>>
>>
>>
--
Karam S. Badesha, CAD Environment Support Team karam.badesha_at_sun.com
Sun Microsystems x48248
410 N. Mary Ave 408.774.8248
Sunnyvale, CA 94085