RE: Database Connection in Logic Beans - pooling? => request cycle

[David Graham]

The request cycle ends when the final view component (JSP) sends its output 
to the browser.  Struts ends its involvement when your Action class returns 
an ActionForward object from its perform method.  Struts forwards to the 
page defined in the ActionForward object and I don't think is involved after 
that point unless your page redirects back to a struts component.

So, I would subclass the ActionServlet (the request starting point) and mark 
the time in the current session.  Then I would mark the time at the end of 
my JSP to find out how long the request took to process.

Dave


>I got the message and I will use the sessionFacade pattern and use the
>connection pool as you advised.
>Nevertheless I would like to know where the request cycle ends in the 
>struts
>framework?
>I didn't find any diagram regarding the request cycle.
>I would like to store (among other things) the time for processing each
>request.
>I suppose I'll have to put the code in the controller component, the
>ActionServlet?
>How can I best achieve this?
>
>Thanks to you all for your advice.
>Frederic
>
>-Original Message-
>From: David Graham [mailto:[EMAIL PROTECTED]]
>Sent: Tuesday, September 03, 2002 6:35 AM
>To: [EMAIL PROTECTED]
>Subject: RE: Database Connection in Logic Beans - pooling?
>
>
>Do NOT save the request into the session.  That's why there is a connection
>pool (DataSource), you take one out, use it, and put it back.  If you don't
>return it you will ruin the whole point of the pool.  The connection pool
>idea was created to avoid the situation you described.  You should always
>ask the pool for a connection when you need one and put it back when
>finished; your application's response time will greatly improve.
>
>Dave
>
> >Thanks to Troy,
> >
> >But I read a lot of Java literature and the struts archive over the past
> >weeks but in the all the examples the connection is retrieved and 
>returned
> >is the same class. I know it is the easiest and the best way to handle 
>the
> >problem.
> >In most cases it provides a solution.
> >I would like to implement a more flexible solution:
> >- Retrieving a connection and saving it in the context (request scope) or
> >saving an id associated with the connection.
> >- When a connection is needed in the request, look first in the context 
>if
> >a
> >connection has already been retrieved.
> >- Based on a parameter => return the connection in the class.
> >- Check at the end of the request if a connection exists, if yes return 
>it
> >to the pool.
> >=> Where does the request cycle ends?
> >At the source I'm a database programmer so I prefer to manage the
> >transactions myself.
> >I think that another advantage of using a same connection through the 
>whole
> >request is the fact that in case of heavy loading, when connections are
> >difficult to obtain, the request can be served as a whole. I prefer X
> >requests with 100% satisfaction and y not satisfied than x+y requests 
>with
> >30% satisfaction. If you understand what I mean?
> >
> >Your help or advice will be appreciated.
> >Frederic
> >
> >I've excluded EJB for my project because most of the data is read only or
> >linked to one user only.
> >
> >-Original Message-
> >From: Troy Hart [mailto:[EMAIL PROTECTED]]
> >Sent: Monday, September 02, 2002 9:17 PM
> >To: Struts Users Mailing List
> >Subject: RE: Database Connection in Logic Beans - pooling?
> >
> >
> >You can solve this problem by providing a business service framework for
> >your application (There has been a lot of talk about this sort of thing
> >on this list...I can't think of a particular thread to reference for you
> >so you may just want to go through the archives). My approach to this
> >problem has been to create a set of very coarse grained business service
> >components (ours is an ecommerce system so we have components like the
> >following: one for cataloging, one for requisitioning, one for order
> >services, and etc...), where each component provides a public API that
> >mirrors the "use-cases" one-to-one (for the most part). I think you will
> >find that the top level "use-cases" defined for your system provide
> >natural scoping boundaries for your transactions, and resource
> >management in general.
> >
> >This approach will leave you with a set of re-usable business components
> >that are not tied to struts and/or the servlet paradigm. Also, this API
> >provides an abstraction that will allow you to hide complexity from your
&

RE: Database Connection in Logic Beans - pooling? => request cycle

[Frederic Laub]

I got the message and I will use the sessionFacade pattern and use the
connection pool as you advised.
Nevertheless I would like to know where the request cycle ends in the struts
framework?
I didn't find any diagram regarding the request cycle.
I would like to store (among other things) the time for processing each
request.
I suppose I'll have to put the code in the controller component, the
ActionServlet?
How can I best achieve this?

Thanks to you all for your advice.
Frederic

-Original Message-
From: David Graham [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, September 03, 2002 6:35 AM
To: [EMAIL PROTECTED]
Subject: RE: Database Connection in Logic Beans - pooling?


Do NOT save the request into the session.  That's why there is a connection
pool (DataSource), you take one out, use it, and put it back.  If you don't
return it you will ruin the whole point of the pool.  The connection pool
idea was created to avoid the situation you described.  You should always
ask the pool for a connection when you need one and put it back when
finished; your application's response time will greatly improve.

Dave

>Thanks to Troy,
>
>But I read a lot of Java literature and the struts archive over the past
>weeks but in the all the examples the connection is retrieved and returned
>is the same class. I know it is the easiest and the best way to handle the
>problem.
>In most cases it provides a solution.
>I would like to implement a more flexible solution:
>- Retrieving a connection and saving it in the context (request scope) or
>saving an id associated with the connection.
>- When a connection is needed in the request, look first in the context if
>a
>connection has already been retrieved.
>- Based on a parameter => return the connection in the class.
>- Check at the end of the request if a connection exists, if yes return it
>to the pool.
>=> Where does the request cycle ends?
>At the source I'm a database programmer so I prefer to manage the
>transactions myself.
>I think that another advantage of using a same connection through the whole
>request is the fact that in case of heavy loading, when connections are
>difficult to obtain, the request can be served as a whole. I prefer X
>requests with 100% satisfaction and y not satisfied than x+y requests with
>30% satisfaction. If you understand what I mean?
>
>Your help or advice will be appreciated.
>Frederic
>
>I've excluded EJB for my project because most of the data is read only or
>linked to one user only.
>
>-Original Message-
>From: Troy Hart [mailto:[EMAIL PROTECTED]]
>Sent: Monday, September 02, 2002 9:17 PM
>To: Struts Users Mailing List
>Subject: RE: Database Connection in Logic Beans - pooling?
>
>
>You can solve this problem by providing a business service framework for
>your application (There has been a lot of talk about this sort of thing
>on this list...I can't think of a particular thread to reference for you
>so you may just want to go through the archives). My approach to this
>problem has been to create a set of very coarse grained business service
>components (ours is an ecommerce system so we have components like the
>following: one for cataloging, one for requisitioning, one for order
>services, and etc...), where each component provides a public API that
>mirrors the "use-cases" one-to-one (for the most part). I think you will
>find that the top level "use-cases" defined for your system provide
>natural scoping boundaries for your transactions, and resource
>management in general.
>
>This approach will leave you with a set of re-usable business components
>that are not tied to struts and/or the servlet paradigm. Also, this API
>provides an abstraction that will allow you to hide complexity from your
>struts actions (or whatever else uses the API). For example, the
>component you expose could be a facade to an EJB Session bean
>(http://java.sun.com/blueprints/corej2eepatterns/Patterns/SessionFacade.htm
l
>).
>
>Anyway, my suggestion is to think about your problem a little
>differently. Sorry if I didn't provide enough details, my intention was
>simply to give a high level overview of how I see the problem and the
>solution. Once again, I would urge to lookup other threads on this topic
>to read what other people have said.
>
>Hope this helps,
>
>Troy
>
>
>On Mon, 2002-09-02 at 10:45, Frederic Laub wrote:
> > Hi,
> >
> > How do achieve the following:
> > In some cases I want to get a connection at the beginning of a request
> > (request scope), pass the same connection to all the java beans that are
> > called in the request and return the connection at the end of the
>request.
> > Where do I put the cod

RE: Database Connection in Logic Beans - pooling?

[David Graham]

Do NOT save the request into the session.  That's why there is a connection 
pool (DataSource), you take one out, use it, and put it back.  If you don't 
return it you will ruin the whole point of the pool.  The connection pool 
idea was created to avoid the situation you described.  You should always 
ask the pool for a connection when you need one and put it back when 
finished; your application's response time will greatly improve.

Dave

>Thanks to Troy,
>
>But I read a lot of Java literature and the struts archive over the past
>weeks but in the all the examples the connection is retrieved and returned
>is the same class. I know it is the easiest and the best way to handle the
>problem.
>In most cases it provides a solution.
>I would like to implement a more flexible solution:
>- Retrieving a connection and saving it in the context (request scope) or
>saving an id associated with the connection.
>- When a connection is needed in the request, look first in the context if 
>a
>connection has already been retrieved.
>- Based on a parameter => return the connection in the class.
>- Check at the end of the request if a connection exists, if yes return it
>to the pool.
>=> Where does the request cycle ends?
>At the source I'm a database programmer so I prefer to manage the
>transactions myself.
>I think that another advantage of using a same connection through the whole
>request is the fact that in case of heavy loading, when connections are
>difficult to obtain, the request can be served as a whole. I prefer X
>requests with 100% satisfaction and y not satisfied than x+y requests with
>30% satisfaction. If you understand what I mean?
>
>Your help or advice will be appreciated.
>Frederic
>
>I've excluded EJB for my project because most of the data is read only or
>linked to one user only.
>
>-Original Message-
>From: Troy Hart [mailto:[EMAIL PROTECTED]]
>Sent: Monday, September 02, 2002 9:17 PM
>To: Struts Users Mailing List
>Subject: RE: Database Connection in Logic Beans - pooling?
>
>
>You can solve this problem by providing a business service framework for
>your application (There has been a lot of talk about this sort of thing
>on this list...I can't think of a particular thread to reference for you
>so you may just want to go through the archives). My approach to this
>problem has been to create a set of very coarse grained business service
>components (ours is an ecommerce system so we have components like the
>following: one for cataloging, one for requisitioning, one for order
>services, and etc...), where each component provides a public API that
>mirrors the "use-cases" one-to-one (for the most part). I think you will
>find that the top level "use-cases" defined for your system provide
>natural scoping boundaries for your transactions, and resource
>management in general.
>
>This approach will leave you with a set of re-usable business components
>that are not tied to struts and/or the servlet paradigm. Also, this API
>provides an abstraction that will allow you to hide complexity from your
>struts actions (or whatever else uses the API). For example, the
>component you expose could be a facade to an EJB Session bean
>(http://java.sun.com/blueprints/corej2eepatterns/Patterns/SessionFacade.html
>).
>
>Anyway, my suggestion is to think about your problem a little
>differently. Sorry if I didn't provide enough details, my intention was
>simply to give a high level overview of how I see the problem and the
>solution. Once again, I would urge to lookup other threads on this topic
>to read what other people have said.
>
>Hope this helps,
>
>Troy
>
>
>On Mon, 2002-09-02 at 10:45, Frederic Laub wrote:
> > Hi,
> >
> > How do achieve the following:
> > In some cases I want to get a connection at the beginning of a request
> > (request scope), pass the same connection to all the java beans that are
> > called in the request and return the connection at the end of the 
>request.
> > Where do I put the code to return the connection to the pool at the end 
>of
> > the request and in case of an error be sure that the connection is
>returned
> > to the pool?
> > A same connection is required when all DML statements throughout a 
>request
> > are part of a same transaction.
> > The commit (or rollback in case of an error) statement is issued at the
>end
> > of the request before the connection is returned to the pool.
> > Sorry if the vocabulary I used is database oriented and not 100 %
> > java/struts compatible.
> >
> > Your help will be appreciated.
> > Frederic
> >
> >
> > -Original Messa

RE: Database Connection in Logic Beans - pooling?

[Troy Hart]

A big problem that you will encounter is reliably trapping the "end" of
the request lifecycle. I haven't looked at filters to see if they
provide a 100% reliable solution for this, they may (I don't know what
happens in this scenario when some component decides to redirect the
request...), or there may be some other creative solution that fits your
needs.

However, I still think the goal should be to encapsulate as much as you
can behind a re-usable business API. Struts is great but you may have a
case for re-use elsewhere. For example, you could be tasked to implement
a messaging system that asynchronously executes business logic based on
the receipt of standard documents that come in from trading partners... 

You can pass a connection to the business components if you insist, but
if the business api is done right it should naturally encapsulate the
boundaries of your transactions. Also, by passing the connection into
the business layer you have tightly coupled the controller and model
layers. However, if this buisiness API only exposes a set of value
objects then the business tier is free to swap the relational database
for an ldap store... This API could be a session facade if you were to
use EJB Session beans, but you are certainly not tied to that approach.

My advice is to take the time to get the abstractions right. Don't
couple the tiers unnecessarily, and plan for re-use. This is just my
opinion and it may or may not be relevant (I don't know your apps
requirements).

Cheers,

Troy



On Mon, 2002-09-02 at 15:02, Frederic Laub wrote:
> Thanks to Troy,
> 
> But I read a lot of Java literature and the struts archive over the past
> weeks but in the all the examples the connection is retrieved and returned
> is the same class. I know it is the easiest and the best way to handle the
> problem.
> In most cases it provides a solution.
> I would like to implement a more flexible solution:
> - Retrieving a connection and saving it in the context (request scope) or
> saving an id associated with the connection.
> - When a connection is needed in the request, look first in the context if a
> connection has already been retrieved.
> - Based on a parameter => return the connection in the class.
> - Check at the end of the request if a connection exists, if yes return it
> to the pool.
> => Where does the request cycle ends?
> At the source I'm a database programmer so I prefer to manage the
> transactions myself.
> I think that another advantage of using a same connection through the whole
> request is the fact that in case of heavy loading, when connections are
> difficult to obtain, the request can be served as a whole. I prefer X
> requests with 100% satisfaction and y not satisfied than x+y requests with
> 30% satisfaction. If you understand what I mean?
> 
> Your help or advice will be appreciated.
> Frederic
> 
> I've excluded EJB for my project because most of the data is read only or
> linked to one user only.
> 
> -Original Message-----
> From: Troy Hart [mailto:[EMAIL PROTECTED]]
> Sent: Monday, September 02, 2002 9:17 PM
> To: Struts Users Mailing List
> Subject: RE: Database Connection in Logic Beans - pooling?
> 
> 
> You can solve this problem by providing a business service framework for
> your application (There has been a lot of talk about this sort of thing
> on this list...I can't think of a particular thread to reference for you
> so you may just want to go through the archives). My approach to this
> problem has been to create a set of very coarse grained business service
> components (ours is an ecommerce system so we have components like the
> following: one for cataloging, one for requisitioning, one for order
> services, and etc...), where each component provides a public API that
> mirrors the "use-cases" one-to-one (for the most part). I think you will
> find that the top level "use-cases" defined for your system provide
> natural scoping boundaries for your transactions, and resource
> management in general.
> 
> This approach will leave you with a set of re-usable business components
> that are not tied to struts and/or the servlet paradigm. Also, this API
> provides an abstraction that will allow you to hide complexity from your
> struts actions (or whatever else uses the API). For example, the
> component you expose could be a facade to an EJB Session bean
> (http://java.sun.com/blueprints/corej2eepatterns/Patterns/SessionFacade.html
> ).
> 
> Anyway, my suggestion is to think about your problem a little
> differently. Sorry if I didn't provide enough details, my intention was
> simply to give a high level overview of how I see the problem and the
> solution. Once again, I would urge to lookup other threads o

RE: Database Connection in Logic Beans - pooling?

[Frederic Laub]

Thanks to Troy,

But I read a lot of Java literature and the struts archive over the past
weeks but in the all the examples the connection is retrieved and returned
is the same class. I know it is the easiest and the best way to handle the
problem.
In most cases it provides a solution.
I would like to implement a more flexible solution:
- Retrieving a connection and saving it in the context (request scope) or
saving an id associated with the connection.
- When a connection is needed in the request, look first in the context if a
connection has already been retrieved.
- Based on a parameter => return the connection in the class.
- Check at the end of the request if a connection exists, if yes return it
to the pool.
=> Where does the request cycle ends?
At the source I'm a database programmer so I prefer to manage the
transactions myself.
I think that another advantage of using a same connection through the whole
request is the fact that in case of heavy loading, when connections are
difficult to obtain, the request can be served as a whole. I prefer X
requests with 100% satisfaction and y not satisfied than x+y requests with
30% satisfaction. If you understand what I mean?

Your help or advice will be appreciated.
Frederic

I've excluded EJB for my project because most of the data is read only or
linked to one user only.

-Original Message-
From: Troy Hart [mailto:[EMAIL PROTECTED]]
Sent: Monday, September 02, 2002 9:17 PM
To: Struts Users Mailing List
Subject: RE: Database Connection in Logic Beans - pooling?


You can solve this problem by providing a business service framework for
your application (There has been a lot of talk about this sort of thing
on this list...I can't think of a particular thread to reference for you
so you may just want to go through the archives). My approach to this
problem has been to create a set of very coarse grained business service
components (ours is an ecommerce system so we have components like the
following: one for cataloging, one for requisitioning, one for order
services, and etc...), where each component provides a public API that
mirrors the "use-cases" one-to-one (for the most part). I think you will
find that the top level "use-cases" defined for your system provide
natural scoping boundaries for your transactions, and resource
management in general.

This approach will leave you with a set of re-usable business components
that are not tied to struts and/or the servlet paradigm. Also, this API
provides an abstraction that will allow you to hide complexity from your
struts actions (or whatever else uses the API). For example, the
component you expose could be a facade to an EJB Session bean
(http://java.sun.com/blueprints/corej2eepatterns/Patterns/SessionFacade.html
).

Anyway, my suggestion is to think about your problem a little
differently. Sorry if I didn't provide enough details, my intention was
simply to give a high level overview of how I see the problem and the
solution. Once again, I would urge to lookup other threads on this topic
to read what other people have said.

Hope this helps,

Troy


On Mon, 2002-09-02 at 10:45, Frederic Laub wrote:
> Hi,
>
> How do achieve the following:
> In some cases I want to get a connection at the beginning of a request
> (request scope), pass the same connection to all the java beans that are
> called in the request and return the connection at the end of the request.
> Where do I put the code to return the connection to the pool at the end of
> the request and in case of an error be sure that the connection is
returned
> to the pool?
> A same connection is required when all DML statements throughout a request
> are part of a same transaction.
> The commit (or rollback in case of an error) statement is issued at the
end
> of the request before the connection is returned to the pool.
> Sorry if the vocabulary I used is database oriented and not 100 %
> java/struts compatible.
>
> Your help will be appreciated.
> Frederic
>
>
> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
> Sent: Monday, September 02, 2002 9:06 AM
> To: Struts Users Mailing List
> Subject: Re: Database Connection in Logic Beans - pooling?
>
>
> Steve McLeod writes:
>
> > I am using:
> > Tomcat 4.0
> > Struts 1.0.2
> >
> > The problem
> > 
> >
> > I have successfully used the Struts database connection pooling in a
trial
> > web app, but as far as I can tell, a reference to the datasource can
only
> be
> > obtained from within an Action class (or directly within a JSP page but
> > let's not think about that today).
> >
> > However I would like to have logic beans which handle database access,
> > rather than have this in the Action class. But I can't get a reference

RE: Database Connection in Logic Beans - pooling?

[Troy Hart]

You can solve this problem by providing a business service framework for
your application (There has been a lot of talk about this sort of thing
on this list...I can't think of a particular thread to reference for you
so you may just want to go through the archives). My approach to this
problem has been to create a set of very coarse grained business service
components (ours is an ecommerce system so we have components like the
following: one for cataloging, one for requisitioning, one for order
services, and etc...), where each component provides a public API that
mirrors the "use-cases" one-to-one (for the most part). I think you will
find that the top level "use-cases" defined for your system provide
natural scoping boundaries for your transactions, and resource
management in general.

This approach will leave you with a set of re-usable business components
that are not tied to struts and/or the servlet paradigm. Also, this API
provides an abstraction that will allow you to hide complexity from your
struts actions (or whatever else uses the API). For example, the
component you expose could be a facade to an EJB Session bean
(http://java.sun.com/blueprints/corej2eepatterns/Patterns/SessionFacade.html).

Anyway, my suggestion is to think about your problem a little
differently. Sorry if I didn't provide enough details, my intention was
simply to give a high level overview of how I see the problem and the
solution. Once again, I would urge to lookup other threads on this topic
to read what other people have said.

Hope this helps,

Troy


On Mon, 2002-09-02 at 10:45, Frederic Laub wrote:
> Hi,
> 
> How do achieve the following:
> In some cases I want to get a connection at the beginning of a request
> (request scope), pass the same connection to all the java beans that are
> called in the request and return the connection at the end of the request.
> Where do I put the code to return the connection to the pool at the end of
> the request and in case of an error be sure that the connection is returned
> to the pool?
> A same connection is required when all DML statements throughout a request
> are part of a same transaction.
> The commit (or rollback in case of an error) statement is issued at the end
> of the request before the connection is returned to the pool.
> Sorry if the vocabulary I used is database oriented and not 100 %
> java/struts compatible.
> 
> Your help will be appreciated.
> Frederic
> 
> 
> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
> Sent: Monday, September 02, 2002 9:06 AM
> To: Struts Users Mailing List
> Subject: Re: Database Connection in Logic Beans - pooling?
> 
> 
> Steve McLeod writes:
> 
> > I am using:
> > Tomcat 4.0
> > Struts 1.0.2
> >
> > The problem
> > 
> >
> > I have successfully used the Struts database connection pooling in a trial
> > web app, but as far as I can tell, a reference to the datasource can only
> be
> > obtained from within an Action class (or directly within a JSP page but
> > let's not think about that today).
> >
> > However I would like to have logic beans which handle database access,
> > rather than have this in the Action class. But I can't get a reference to
> > the datasource from the logic bean because it doesn't have a
> ServletContext
> > to which I can get a handle.
> >
> > I have toyed with various ideas:
> > - Initialise a logic bean by passing it a reference to the Servlet
> > - Acquire a connection in the Action class and pass that to the bean
> >
> > But really, I would rather the logic bean know inherently how to acquire a
> > database connection.
> >
> > My current workaround is to not use the Struts connection pooling, and
> > rather to manually create a connection each time database access needs to
> be
> > done, then destroy it. But this is clearly not suitable for our production
> > environment.
> 
> There are a few ways to solve your problem. One way would be to bind a
> datasource to some JNDI name that your logic beans are aware of. Then, using
> that name, your logic beans can lookup the datasource completely independent
> of struts.
> 
> Give it a try,
> 
> Troy
> 
> >
> >
> > The context of my problem
> > ==
> >
> > I want to use some code like this in a JSP:
> >
> >  > class="au.com.sunesis.timesheets.ClientManager" />
> > 
> > 
> > #
> > Client
> > Active
> > 
> >  > type="au.com.sunesis.timesheets.Client">
> > 
> > 
> > 
> > 

RE: Database Connection in Logic Beans - pooling?

[Frederic Laub]

Hi,

How do achieve the following:
In some cases I want to get a connection at the beginning of a request
(request scope), pass the same connection to all the java beans that are
called in the request and return the connection at the end of the request.
Where do I put the code to return the connection to the pool at the end of
the request and in case of an error be sure that the connection is returned
to the pool?
A same connection is required when all DML statements throughout a request
are part of a same transaction.
The commit (or rollback in case of an error) statement is issued at the end
of the request before the connection is returned to the pool.
Sorry if the vocabulary I used is database oriented and not 100 %
java/struts compatible.

Your help will be appreciated.
Frederic


-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
Sent: Monday, September 02, 2002 9:06 AM
To: Struts Users Mailing List
Subject: Re: Database Connection in Logic Beans - pooling?


Steve McLeod writes:

> I am using:
> Tomcat 4.0
> Struts 1.0.2
>
> The problem
> 
>
> I have successfully used the Struts database connection pooling in a trial
> web app, but as far as I can tell, a reference to the datasource can only
be
> obtained from within an Action class (or directly within a JSP page but
> let's not think about that today).
>
> However I would like to have logic beans which handle database access,
> rather than have this in the Action class. But I can't get a reference to
> the datasource from the logic bean because it doesn't have a
ServletContext
> to which I can get a handle.
>
> I have toyed with various ideas:
> - Initialise a logic bean by passing it a reference to the Servlet
> - Acquire a connection in the Action class and pass that to the bean
>
> But really, I would rather the logic bean know inherently how to acquire a
> database connection.
>
> My current workaround is to not use the Struts connection pooling, and
> rather to manually create a connection each time database access needs to
be
> done, then destroy it. But this is clearly not suitable for our production
> environment.

There are a few ways to solve your problem. One way would be to bind a
datasource to some JNDI name that your logic beans are aware of. Then, using
that name, your logic beans can lookup the datasource completely independent
of struts.

Give it a try,

Troy

>
>
> The context of my problem
> ==
>
> I want to use some code like this in a JSP:
>
>  class="au.com.sunesis.timesheets.ClientManager" />
> 
> 
> #
> Client
> Active
> 
>  type="au.com.sunesis.timesheets.Client">
> 
> 
> 
> 
> 
> 
>
>
> The idea is that ClientManager is used to handle all general database
tasks
> for the Client bean (which maps to a Client entity in the database).
> ClientManager.getClients() connects to the database, creates an ArrayList
of
> Client objects, one for each row in the database, and returns the
ArrayList.
>
> ClientManager has other methods, such as:
> - ClientManager.delete(Client c), which deletes the row in the
> database entity corresponding to the specified client.
> - ClientManager.findByPrimaryKey(int ID) which returns the Client
> which matches the specified ID
> - ClientManager.save(Client c), which stores the client in the
> database, creating or updating as necessary
>
> So an Action class can also call any of these directly, and it really
> shouldn't care about how these work and how they store to/retrieve from
the
> database. But I can't think of the elegant way to do this and still be
able
> to use the Struts connection pooling.
>
> Any thoughts?
>
> Thanks
>
> Steve McLeod
>
>
>


--
To unsubscribe, e-mail:
<mailto:[EMAIL PROTECTED]>
For additional commands, e-mail:
<mailto:[EMAIL PROTECTED]>




--
To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>

Re: Database Connection in Logic Beans - pooling?

[thart]

Steve McLeod writes: 

> I am using:
> Tomcat 4.0
> Struts 1.0.2
>  
> The problem
> 
>  
> I have successfully used the Struts database connection pooling in a trial
> web app, but as far as I can tell, a reference to the datasource can only be
> obtained from within an Action class (or directly within a JSP page but
> let's not think about that today).
>  
> However I would like to have logic beans which handle database access,
> rather than have this in the Action class. But I can't get a reference to
> the datasource from the logic bean because it doesn't have a ServletContext
> to which I can get a handle.
>  
> I have toyed with various ideas:
> - Initialise a logic bean by passing it a reference to the Servlet
> - Acquire a connection in the Action class and pass that to the bean
>  
> But really, I would rather the logic bean know inherently how to acquire a
> database connection.
>  
> My current workaround is to not use the Struts connection pooling, and
> rather to manually create a connection each time database access needs to be
> done, then destroy it. But this is clearly not suitable for our production
> environment.

There are a few ways to solve your problem. One way would be to bind a 
datasource to some JNDI name that your logic beans are aware of. Then, using 
that name, your logic beans can lookup the datasource completely independent 
of struts. 

Give it a try, 

Troy 

>  
>  
> The context of my problem
> ==
>  
> I want to use some code like this in a JSP:
>  
>  class="au.com.sunesis.timesheets.ClientManager" />
> 
> 
> #
> Client
> Active
> 
>  type="au.com.sunesis.timesheets.Client">
> 
> 
> 
> 
> 
> 
>  
>  
> The idea is that ClientManager is used to handle all general database tasks
> for the Client bean (which maps to a Client entity in the database).
> ClientManager.getClients() connects to the database, creates an ArrayList of
> Client objects, one for each row in the database, and returns the ArrayList.
>  
> ClientManager has other methods, such as:
> - ClientManager.delete(Client c), which deletes the row in the
> database entity corresponding to the specified client.
> - ClientManager.findByPrimaryKey(int ID) which returns the Client
> which matches the specified ID
> - ClientManager.save(Client c), which stores the client in the
> database, creating or updating as necessary
>  
> So an Action class can also call any of these directly, and it really
> shouldn't care about how these work and how they store to/retrieve from the
> database. But I can't think of the elegant way to do this and still be able
> to use the Struts connection pooling.
>  
> Any thoughts?
>  
> Thanks
>  
> Steve McLeod
>  
>  
>  
 

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

RE: Database Connection in Logic Beans - pooling?

[Miguel Angel Mulero Martinez]

You can too use the DBCP from jakarta, I'm using it and works perfectly:

http://jakarta.apache.org/tomcat/tomcat-4.1-doc/jndi-datasource-examples-how
to.html



-Mensaje original-
De: Steve McLeod [mailto:[EMAIL PROTECTED]]
Enviado el: lunes, 02 de septiembre de 2002 2:10
Para: '[EMAIL PROTECTED]'
Asunto: Database Connection in Logic Beans - pooling?

I am using:
Tomcat 4.0
Struts 1.0.2

The problem


I have successfully used the Struts database connection pooling in a
trial
web app, but as far as I can tell, a reference to the datasource can
only be
obtained from within an Action class (or directly within a JSP page but
let's not think about that today).

However I would like to have logic beans which handle database access,
rather than have this in the Action class. But I can't get a reference
to
the datasource from the logic bean because it doesn't have a
ServletContext
to which I can get a handle.

I have toyed with various ideas:
- Initialise a logic bean by passing it a reference to the Servlet
- Acquire a connection in the Action class and pass that to the bean

But really, I would rather the logic bean know inherently how to acquire
a
database connection.

My current workaround is to not use the Struts connection pooling, and
rather to manually create a connection each time database access needs
to be
done, then destroy it. But this is clearly not suitable for our
production
environment.


The context of my problem
==

I want to use some code like this in a JSP:




#
Client
Active










The idea is that ClientManager is used to handle all general database
tasks
for the Client bean (which maps to a Client entity in the database).
ClientManager.getClients() connects to the database, creates an
ArrayList of
Client objects, one for each row in the database, and returns the
ArrayList.

ClientManager has other methods, such as:
- ClientManager.delete(Client c), which deletes the row in the
database entity corresponding to the specified client.
- ClientManager.findByPrimaryKey(int ID) which returns the
Client
which matches the specified ID
- ClientManager.save(Client c), which stores the client in the
database, creating or updating as necessary

So an Action class can also call any of these directly, and it really
shouldn't care about how these work and how they store to/retrieve from
the
database. But I can't think of the elegant way to do this and still be
able
to use the Struts connection pooling.

Any thoughts?

Thanks

Steve McLeod




--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: Database Connection in Logic Beans - pooling?

[David Graham]

Here's how I do it:
I defined a Database class with a constructor that takes a Datasource 
object.  It also has a static getSystemDatabase() method and a getConnection 
method.  I subclassed the struts ActionServlet and get ahold of its 
DataSource (defined in struts-config.xml) and pass it into my Database 
object.  Then anywhere in the system I can call 
Database.getSystemDatabase().getConnection() to get a connection to the 
database.

This also works outside of webapps because the Database class just knows 
about DataSources and not struts stuff.  Also, this lets your logic beans 
not know about servlets or struts which is much cleaner in my opinion.

Hope that helps,
Dave


>From: Steve McLeod <[EMAIL PROTECTED]>
>Reply-To: "Struts Users Mailing List" <[EMAIL PROTECTED]>
>To: "'[EMAIL PROTECTED]'" <[EMAIL PROTECTED]>
>Subject: Database Connection in Logic Beans - pooling?
>Date: Mon, 2 Sep 2002 10:09:47 +1000
>
>I am using:
>Tomcat 4.0
>Struts 1.0.2
>
>The problem
>
>
>I have successfully used the Struts database connection pooling in a trial
>web app, but as far as I can tell, a reference to the datasource can only 
>be
>obtained from within an Action class (or directly within a JSP page but
>let's not think about that today).
>
>However I would like to have logic beans which handle database access,
>rather than have this in the Action class. But I can't get a reference to
>the datasource from the logic bean because it doesn't have a ServletContext
>to which I can get a handle.
>
>I have toyed with various ideas:
>- Initialise a logic bean by passing it a reference to the Servlet
>- Acquire a connection in the Action class and pass that to the bean
>
>But really, I would rather the logic bean know inherently how to acquire a
>database connection.
>
>My current workaround is to not use the Struts connection pooling, and
>rather to manually create a connection each time database access needs to 
>be
>done, then destroy it. But this is clearly not suitable for our production
>environment.
>
>
>The context of my problem
>==
>
>I want to use some code like this in a JSP:
>
>class="au.com.sunesis.timesheets.ClientManager" />
>
> 
> #
> Client
> Active
> 
>type="au.com.sunesis.timesheets.Client">
> 
> 
> 
> 
> 
>
>
>
>The idea is that ClientManager is used to handle all general database tasks
>for the Client bean (which maps to a Client entity in the database).
>ClientManager.getClients() connects to the database, creates an ArrayList 
>of
>Client objects, one for each row in the database, and returns the 
>ArrayList.
>
>ClientManager has other methods, such as:
>- ClientManager.delete(Client c), which deletes the row in the
>database entity corresponding to the specified client.
>- ClientManager.findByPrimaryKey(int ID) which returns the Client
>which matches the specified ID
>- ClientManager.save(Client c), which stores the client in the
>database, creating or updating as necessary
>
>So an Action class can also call any of these directly, and it really
>shouldn't care about how these work and how they store to/retrieve from the
>database. But I can't think of the elegant way to do this and still be able
>to use the Struts connection pooling.
>
>Any thoughts?
>
>Thanks
>
>Steve McLeod
>
>
>




_
Send and receive Hotmail on your mobile device: http://mobile.msn.com


--
To unsubscribe, e-mail:   
For additional commands, e-mail: