From: Ken Paulsen <Ken.Paulsen_at_Sun.COM>
Date: Wed, 21 Feb 2007 14:10:18 -0800

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