Re: Tomcat 4.x and Database Connection Pooling

[Soefara Redzuan]

I don't understand why you need it to be abstract.

I don't think that Struts necessarily changes it either.

Remember that your servlets calling the class are multi-threaded. That's the 
one thing that I completely misunderstood when I first started writing 
servlets.

As I understand it, just say 3 simultaneous requests come in for the servlet 
that uses your DatabaseManager class. The servlet will create 3 threads to 
deal with these requests. Each thread will create an instance of your 
DatabaseManager class (unless you make it a static class variable which 
would probably be a bad idea).  Each instance of the DatabaseManager class 
(one instance for each servlet thread) will then grab a database connection 
from the database pool manager using JNDI. Therefore, do not employ global 
static variables or else you'll need to use synchronized and that will also 
defeat the object of database pooling.

Please correct me if I'm wrong and sorry if I have not answered your 
question. Be aware that I'm not a java maestro.

Soefara

>From: Ric Searle <[EMAIL PROTECTED]>
>Reply-To: "Tomcat Users List" <[EMAIL PROTECTED]>
>To: "Tomcat Users List" <[EMAIL PROTECTED]>
>Subject: Re: Tomcat 4.x and Database Connection Pooling
>Date: Thu, 11 Apr 2002 20:17:32 +0100
>
>Thanks to everyone who's commented on this - I can't believe that I
>hadn't come across the JNDI solution, but it's working beautifully now.
>So onto the next, closely related issue...
>
>I'm accessing my database, via JNDI, using a class called
>DatabaseManager.  My aim is that this class abstracts the database
>backend, so I can just call addUser(myUser), and it will take care of
>the SQL stuff behind the scenes.  At the moment,  this DatabaseManager
>contains code similar to Soefara's below to get a connection for itself
>whenever it has to make a db request.
>
>My confusion is what to do with this class - Should I declare it as
>abstract?  Does that ruin some of the pooling stuff?  I would really
>like to be able to create a global instance of this class, instantiated
>when the server starts, since individual requests don't need their own
>DatabaseManager.  But I'm using Struts, and I don't know how to do
>that!  Arghh...
>
>Any thoughts/experiences?
>
>   Ric Searle
>   Web Application Developer
>   --
>   Dialogue Communications Ltd
>
>   http://www.dialogue.co.uk
>   +44 (0) 114 221 0307
>
>On Thursday, April 11, 2002, at 06:02  pm, Craig R. McClanahan wrote:
>
>>
>>
>>On Thu, 11 Apr 2002, Soefara Redzuan wrote:
>>
>>>Date: Thu, 11 Apr 2002 10:46:14 +0800
>>>From: Soefara Redzuan <[EMAIL PROTECTED]>
>>>Reply-To: Tomcat Users List <[EMAIL PROTECTED]>
>>>To: [EMAIL PROTECTED]
>>>Subject: Re: Tomcat 4.x and Database Connection Pooling
>>>
>>>>Tomcat:  As far as I'm concerned, JNDI support is a "now and forever
>>>>more"
>>>>feature of Tomcat 4 and later.  It's the standard access mechanism
>>>>for J2EE
>>>>app servers as well.
>>>
>>>This is what I love to hear. With so many changes (servlets to JSP to
>>>Struts) over the last few years, future-proofing is so important.
>>>
>>>>Recommendation:  If you can, you should use JNDI based access to data
>>>>sources.  This is both portable across containers, and portable across
>>>>Struts versus non-Struts applications.
>>>
>>>>In addition, it can be used from
>>>>directly from within a JavaBean implementing your business logic,
>>>>without requiring a reference to ActionServlet or the servlet context
>>>>(or
>>>>the web layer at all).
>>>
>>>Really ? This is incredibly important news to me. I've been acquiring
>>>the
>>>JNDI resource within my servlet then passing it as a parameter to my
>>>Javabean which is a terrible mechanism because it makes my javabean
>>>dependent on the servlet :(
>>>
>>>So, are we saying that once we've set up a pooled database connection
>>>JNDI
>>>resource in server.xml and web.xml, any Javabean that is called by a
>>>serlvet
>>>or JSP can make use of this JNDI resource directly like this
>>>
>>>
>>>In the javabean.
>>>
>>>import javax.naming.NamingException;
>>>import javax.naming.Context;
>>>import javax.naming.InitialContext;
>>>import javax.naming.NamingEnumeration;
>>>import javax.naming.directory.InitialDirContext;
>>>
>>>

Re: Tomcat 4.x and Database Connection Pooling

[Soefara Redzuan]

> > In the javabean.
> > 
> > import javax.naming.NamingException;
> > import javax.naming.Context;
> > import javax.naming.InitialContext;
> > import javax.naming.NamingEnumeration;
> > import javax.naming.directory.InitialDirContext;
> >
> > class mybean() {
> > java.sql.Connection conn
> > 
> > get getPooledDatabaseConnection() {
> > Context ctx = new  InitialContext();
> > Context envCtx = (Context) ctx.lookup("java:/comp/env/");
> > DataSource ds = (DataSource) envCtx.lookup("jdbc/dbpool");
> > conn = ds.getConnection();
> > }
> > ...
> > }
> >
> > If so, this is going to make development much easier. :-)
> >
>
>Yep ... that is exactly the pattern you can use.  Nice, isn't it?

It's so good we're updating all of our code to use this.

Now the whole MVC framework finally makes sense :-)
At least in a webapp, that is. I'm not sure how a standalone application 
would be able to provide the JNDI environment to the same Javabeans but I'll 
check the Sun JNDI mailing list.

Thank you for all the great work on Tomcat,

Soefara.

_
Chat with friends online, try MSN Messenger: http://messenger.msn.com


--
To unsubscribe:   
For additional commands: 
Troubles with the list: 

Re: Tomcat 4.x and Database Connection Pooling

[Ric Searle]

Thanks to everyone who's commented on this - I can't believe that I 
hadn't come across the JNDI solution, but it's working beautifully now.  
So onto the next, closely related issue...

I'm accessing my database, via JNDI, using a class called 
DatabaseManager.  My aim is that this class abstracts the database 
backend, so I can just call addUser(myUser), and it will take care of 
the SQL stuff behind the scenes.  At the moment,  this DatabaseManager 
contains code similar to Soefara's below to get a connection for itself 
whenever it has to make a db request.

My confusion is what to do with this class - Should I declare it as 
abstract?  Does that ruin some of the pooling stuff?  I would really 
like to be able to create a global instance of this class, instantiated 
when the server starts, since individual requests don't need their own 
DatabaseManager.  But I'm using Struts, and I don't know how to do 
that!  Arghh...

Any thoughts/experiences?

   Ric Searle
   Web Application Developer
   --
   Dialogue Communications Ltd

   http://www.dialogue.co.uk
   +44 (0) 114 221 0307

On Thursday, April 11, 2002, at 06:02  pm, Craig R. McClanahan wrote:

>
>
> On Thu, 11 Apr 2002, Soefara Redzuan wrote:
>
>> Date: Thu, 11 Apr 2002 10:46:14 +0800
>> From: Soefara Redzuan <[EMAIL PROTECTED]>
>> Reply-To: Tomcat Users List <[EMAIL PROTECTED]>
>> To: [EMAIL PROTECTED]
>> Subject: Re: Tomcat 4.x and Database Connection Pooling
>>
>>> Tomcat:  As far as I'm concerned, JNDI support is a "now and forever 
>>> more"
>>> feature of Tomcat 4 and later.  It's the standard access mechanism 
>>> for J2EE
>>> app servers as well.
>>
>> This is what I love to hear. With so many changes (servlets to JSP to
>> Struts) over the last few years, future-proofing is so important.
>>
>>> Recommendation:  If you can, you should use JNDI based access to data
>>> sources.  This is both portable across containers, and portable across
>>> Struts versus non-Struts applications.
>>
>>> In addition, it can be used from
>>> directly from within a JavaBean implementing your business logic,
>>> without requiring a reference to ActionServlet or the servlet context 
>>> (or
>>> the web layer at all).
>>
>> Really ? This is incredibly important news to me. I've been acquiring 
>> the
>> JNDI resource within my servlet then passing it as a parameter to my
>> Javabean which is a terrible mechanism because it makes my javabean
>> dependent on the servlet :(
>>
>> So, are we saying that once we've set up a pooled database connection 
>> JNDI
>> resource in server.xml and web.xml, any Javabean that is called by a 
>> serlvet
>> or JSP can make use of this JNDI resource directly like this
>>
>>
>> In the javabean.
>> 
>> import javax.naming.NamingException;
>> import javax.naming.Context;
>> import javax.naming.InitialContext;
>> import javax.naming.NamingEnumeration;
>> import javax.naming.directory.InitialDirContext;
>>
>> class mybean() {
>> java.sql.Connection conn
>> 
>> get getPooledDatabaseConnection() {
>> Context ctx = new  InitialContext();
>>  Context envCtx = (Context) ctx.lookup("java:/comp/env/");
>>  DataSource ds = (DataSource) envCtx.lookup("jdbc/dbpool");
>>  conn = ds.getConnection();
>> }
>> ...
>> }
>>
>> If so, this is going to make development much easier. :-)
>>
>
> Yep ... that is exactly the pattern you can use.  Nice, isn't it?
>
>> Soefara.
>>
>
> Craig
>
>
> --
> To unsubscribe:   <mailto:[EMAIL PROTECTED]>
> For additional commands: <mailto:[EMAIL PROTECTED]>
> Troubles with the list: <mailto:[EMAIL PROTECTED]>
>
>



--
To unsubscribe:   <mailto:[EMAIL PROTECTED]>
For additional commands: <mailto:[EMAIL PROTECTED]>
Troubles with the list: <mailto:[EMAIL PROTECTED]>

Re: Tomcat 4.x and Database Connection Pooling

[Craig R. McClanahan]

On Thu, 11 Apr 2002, Soefara Redzuan wrote:

> Date: Thu, 11 Apr 2002 10:46:14 +0800
> From: Soefara Redzuan <[EMAIL PROTECTED]>
> Reply-To: Tomcat Users List <[EMAIL PROTECTED]>
> To: [EMAIL PROTECTED]
> Subject: Re: Tomcat 4.x and Database Connection Pooling
>
> >Tomcat:  As far as I'm concerned, JNDI support is a "now and forever more"
> >feature of Tomcat 4 and later.  It's the standard access mechanism for J2EE
> >app servers as well.
>
> This is what I love to hear. With so many changes (servlets to JSP to
> Struts) over the last few years, future-proofing is so important.
>
> >Recommendation:  If you can, you should use JNDI based access to data
> >sources.  This is both portable across containers, and portable across
> >Struts versus non-Struts applications.
>
> >In addition, it can be used from
> >directly from within a JavaBean implementing your business logic,
> >without requiring a reference to ActionServlet or the servlet context (or
> >the web layer at all).
>
> Really ? This is incredibly important news to me. I've been acquiring the
> JNDI resource within my servlet then passing it as a parameter to my
> Javabean which is a terrible mechanism because it makes my javabean
> dependent on the servlet :(
>
> So, are we saying that once we've set up a pooled database connection JNDI
> resource in server.xml and web.xml, any Javabean that is called by a serlvet
> or JSP can make use of this JNDI resource directly like this
>
>
> In the javabean.
> 
> import javax.naming.NamingException;
> import javax.naming.Context;
> import javax.naming.InitialContext;
> import javax.naming.NamingEnumeration;
> import javax.naming.directory.InitialDirContext;
>
> class mybean() {
> java.sql.Connection conn
> 
> get getPooledDatabaseConnection() {
> Context ctx = new  InitialContext();
>   Context envCtx = (Context) ctx.lookup("java:/comp/env/");
>   DataSource ds = (DataSource) envCtx.lookup("jdbc/dbpool");
>   conn = ds.getConnection();
> }
> ...
> }
>
> If so, this is going to make development much easier. :-)
>

Yep ... that is exactly the pattern you can use.  Nice, isn't it?

> Soefara.
>

Craig


--
To unsubscribe:   <mailto:[EMAIL PROTECTED]>
For additional commands: <mailto:[EMAIL PROTECTED]>
Troubles with the list: <mailto:[EMAIL PROTECTED]>

Re: Tomcat 4.x and Database Connection Pooling

[Nikola Milutinovic]

> > Struts provides a basic Connection Pool, but user comments suggest that
> > this is not suitable for large-scale, high-traffic applications, and
> > also that it will soon be removed from Struts in favour of a
> > container-managed connection pool
> 
> So what will Tomcat Users do? Will Tomcat get a container manages connection
> pool?
> What is the reason for removing it form Struts?

Struts, as I see it, is just an application framework. Connection pooling is a job for 
the JEE container, be it Tomcat or JBoss (or any other commercial).

Nix.

Re: Tomcat 4.x and Database Connection Pooling

[Nikola Milutinovic]

> Performance isn't so important as future-proofing - I don't want to have 
> to re-write the db interface when struts drops it's connection pool 
> provision, for example.
> 
> I believe that mm.mysql does support pooling, although I take your point 
> that others may not.  I can't see us moving away from MySQL at the 
> moment, so that's fine.
> 
> My use of the database is really quite simple, so I'm sure that commons 
> would be fine, but at the moment I don't know where to start integrating 
> it with my Struts project.  Does the container manage the pool (i.e. 
> some server.xml configuration needed)? Or do I instantiate and manage 
> the pool from within my application, and if so, how?

I believe the correct approach is to let container handle setting up the pool. Look at 
JNDI-Resources HOWTO in Tomcat's docs.

Nix.

Re: Tomcat 4.x and Database Connection Pooling

[Soefara Redzuan]

>Tomcat:  As far as I'm concerned, JNDI support is a "now and forever more" 
>feature of Tomcat 4 and later.  It's the standard access mechanism for J2EE 
>app servers as well.

This is what I love to hear. With so many changes (servlets to JSP to 
Struts) over the last few years, future-proofing is so important.

>Recommendation:  If you can, you should use JNDI based access to data
>sources.  This is both portable across containers, and portable across
>Struts versus non-Struts applications.

>In addition, it can be used from
>directly from within a JavaBean implementing your business logic,
>without requiring a reference to ActionServlet or the servlet context (or 
>the web layer at all).

Really ? This is incredibly important news to me. I've been acquiring the 
JNDI resource within my servlet then passing it as a parameter to my 
Javabean which is a terrible mechanism because it makes my javabean 
dependent on the servlet :(

So, are we saying that once we've set up a pooled database connection JNDI 
resource in server.xml and web.xml, any Javabean that is called by a serlvet 
or JSP can make use of this JNDI resource directly like this


In the javabean.

import javax.naming.NamingException;
import javax.naming.Context;
import javax.naming.InitialContext;
import javax.naming.NamingEnumeration;
import javax.naming.directory.InitialDirContext;

class mybean() {
java.sql.Connection conn

get getPooledDatabaseConnection() {
Context ctx = new  InitialContext();
Context envCtx = (Context) ctx.lookup("java:/comp/env/");
DataSource ds = (DataSource) envCtx.lookup("jdbc/dbpool");
conn = ds.getConnection();
}
...
}

If so, this is going to make development much easier. :-)

Soefara.




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


--
To unsubscribe:   
For additional commands: 
Troubles with the list: 

Re: Tomcat 4.x and Database Connection Pooling

[rainer jünger]

Hi Craig,

> > Sorry somehow I don't understand your answer.
> Struts is ***NOT*** going to remove its own connection pool :-).
Thanks thats an answer even I can understand ; ).

> However, the internal implementation is changing in Struts 1.1 to use the
> commons-dbcp implementation underneath.
this might answer the primar question form Ric as well. 
 
> Recommendation:  If you can, you should use JNDI 
thanks I 'll consider it!

> Craig
Your answer helped me now a lot.
Rainer



--
To unsubscribe:   
For additional commands: 
Troubles with the list: 

Re: Tomcat 4.x and Database Connection Pooling

[Craig R. McClanahan]

On Wed, 10 Apr 2002, rainer jünger wrote:

> Date: Wed, 10 Apr 2002 18:42:39 +0200
> From: rainer jünger <[EMAIL PROTECTED]>
> Reply-To: Tomcat Users List <[EMAIL PROTECTED]>
> To: Tomcat Users List <[EMAIL PROTECTED]>
> Subject: Re: Tomcat 4.x and Database Connection Pooling
>
> Hi Craig,
>
> > > So what will Tomcat Users do? Will Tomcat get a container manages
> connection
> > > pool?
> >
> > http://jakarta.apache.org/tomcat/tomcat-4.0-doc/jndi-resources-howto.html
> >
> > > What is the reason for removing it form Struts?
> >
> > That was a hypothetical example of a possible future situation that would
> > cause the need to change your code.
>
> Sorry somehow I don't understand your answer.

Struts is ***NOT*** going to remove its own connection pool :-).

However, the internal implementation is changing in Struts 1.1 to use the
commons-dbcp implementation underneath.

The person who made this comment was illustrating a *possible* scenario:
- You write your app against the Struts APIs
- Struts removed its connection pool
- You now have to rewrite your apps

Although this particular scenario won't happen, it does illustrate the
potential for problems of reliance on specific APIs versus standardized
approaches (when they exist).

> Did you wont to give me a hint that I can avoid to change the code in future
> by using JNDI?
>

Struts developers who are writing apps for J2EE app servers, or servlet
containers that support JNDI, should definitely use JNDI based data
sources.  This is the standard, portable, API for accessing resources.

> Still, what will happen to the Connection Pooling in future in Struts or in
> Tomcat?
>

Struts:  The connection pool API (org.apache.struts.util.GenericDataSource),
the corresponding configuration in struts-config.xml, and the way to retrieve
data sources from ActionServlet, will remain in Struts -- backwards
compatibility is a key Struts feature.  The internal implementation will
change, but the APIs will not.

Tomcat:  As far as I'm concerned, JNDI support is a "now and forever more"
feature of Tomcat 4 and later.  It's the standard access mechanism for
J2EE app servers as well.

Recommendation:  If you can, you should use JNDI based access to data
sources.  This is both portable across containers, and portable across
Struts versus non-Struts applications.  In addition, it can be used from
directly from within a JavaBean implementing your business logic, without
requiring a reference to ActionServlet or the servlet context (or the web
layer at all).

> thanks,
> rainer juenger
>

Craig


--
To unsubscribe:   <mailto:[EMAIL PROTECTED]>
For additional commands: <mailto:[EMAIL PROTECTED]>
Troubles with the list: <mailto:[EMAIL PROTECTED]>

Re: Tomcat 4.x and Database Connection Pooling

[rainer jünger]

Hi Jim,



> If you are looking for connection pooling which will work with any
database
> check out DbConnectionBroker at http://www.javaexchange.com/


DbConnectionBroker is only providing as the developer calls it a "2 Tier"
model. So there is not actually a Connection Pool that manages the
connection independently and the application is only taking and giving back
connections.

rainer juenger


--
To unsubscribe:   
For additional commands: 
Troubles with the list: 

Re: Tomcat 4.x and Database Connection Pooling

[rainer jünger]

Hi Craig,

> > So what will Tomcat Users do? Will Tomcat get a container manages
connection
> > pool?
>
> http://jakarta.apache.org/tomcat/tomcat-4.0-doc/jndi-resources-howto.html
>
> > What is the reason for removing it form Struts?
>
> That was a hypothetical example of a possible future situation that would
> cause the need to change your code.

Sorry somehow I don't understand your answer.
Did you wont to give me a hint that I can avoid to change the code in future
by using JNDI?

Still, what will happen to the Connection Pooling in future in Struts or in
Tomcat?

thanks,
rainer juenger



--
To unsubscribe:   
For additional commands: 
Troubles with the list: 

RE: Tomcat 4.x and Database Connection Pooling

[Jim Urban]

If you are looking for connection pooling which will work with any database
check out DbConnectionBroker at http://www.javaexchange.com/

Jim

> -Original Message-
> From: Ric Searle [mailto:[EMAIL PROTECTED]]
> Sent: Wednesday, April 10, 2002 10:23 AM
> To: Tomcat Users List
> Subject: Re: Tomcat 4.x and Database Connection Pooling
>
>
> Not sure - probably a little out of my depth here, but poolman
> (www.codestudio.com), which used to do connection pooling stuff is no
> longer available, and it's author claims that:
>
>   "If you are looking for connection and object pooling
>   mechanisms, they can now be found in application
>   servers such as JRun, Tomcat and the Jakarta Project,
>   and other J2EE products and servers."
>
> Which is where my journey started...!
>
>Ric Searle
>Web Application Developer
>--
>Dialogue Communications Ltd
>
>http://www.dialogue.co.uk
>+44 (0) 114 221 0307
>
>
> On Wednesday, April 10, 2002, at 04:18  pm, rainer jünger wrote:
>
> > Hi Ric,
> >
> >> Struts provides a basic Connection Pool, but user comments suggest that
> >> this is not suitable for large-scale, high-traffic applications, and
> >> also that it will soon be removed from Struts in favour of a
> >> container-managed connection pool
> >
> > So what will Tomcat Users do? Will Tomcat get a container manages
> > connection
> > pool?
> > What is the reason for removing it form Struts?
> >
> > R.
> >
>
>
> --
> To unsubscribe:   <mailto:[EMAIL PROTECTED]>
> For additional commands: <mailto:[EMAIL PROTECTED]>
> Troubles with the list: <mailto:[EMAIL PROTECTED]>
>
>


--
To unsubscribe:   <mailto:[EMAIL PROTECTED]>
For additional commands: <mailto:[EMAIL PROTECTED]>
Troubles with the list: <mailto:[EMAIL PROTECTED]>

Re: Tomcat 4.x and Database Connection Pooling

[Ken Anderson]

dbConnectionBroker works well, is easy to use.
Just drop the 5k jar into your $tocmat_home/webapp/app/lib directory
http://www.javaexchange.com/
Example:
http://www.javaexchange.com/Example1.html

Ken
p.s. sorry about my posts to the list yesterday with bad date. :-(



Ric Searle wrote:
> Hi,
> 
> I'm developing a web application using the Struts framework, running on 
> Tomcat 4.0.3, from which I need to access a MySQL database.  I've read 
> various mailing lists etc looking for the best way to achieve this, but 
> not had much luck.
> 
> Struts provides a basic Connection Pool, but user comments suggest that 
> this is not suitable for large-scale, high-traffic applications, and 
> also that it will soon be removed from Struts in favour of a 
> container-managed connection pool.  I've found references to 
> DbConnectionBroker and Jakarta's commons-dbcp module.  It seems to make 
> sense to use the latter, to keep the entire project neatly under the 
> Jakarta project, but I'd appreciate comments on either.
> 
> I'm fairly new to Tomcat (and Servlets), and I can't find any simple 
> examples of how to use one of these connection pools.  I suspect that I 
> need to add something to my server.xml, and instantiate the pool in the 
> servlet's init() method.  It would be greatly appreciated if someone 
> could provide some simple instructions to get me started - sample code 
> would be fantastic.
> 
> I hope to write about my experiences with this once I understand it - 
> there seems to be a need for documentation in this area.
> 
> Regards,
> 
>   Ric Searle
>   Web Application Developer
>   --
>   Dialogue Communications Ltd
> 
>   http://www.dialogue.co.uk
>   +44 (0) 114 221 0307
> 
> 
> -- 
> To unsubscribe:   
> For additional commands: 
> Troubles with the list: 
> 
> 
> 



--
To unsubscribe:   
For additional commands: 
Troubles with the list: 

Re: Tomcat 4.x and Database Connection Pooling

[Craig R. McClanahan]

On Wed, 10 Apr 2002, rainer jünger wrote:

> Date: Wed, 10 Apr 2002 17:18:34 +0200
> From: rainer jünger <[EMAIL PROTECTED]>
> Reply-To: Tomcat Users List <[EMAIL PROTECTED]>
> To: Tomcat Users List <[EMAIL PROTECTED]>
> Subject: Re: Tomcat 4.x and Database Connection Pooling
>
> Hi Ric,
>
> > Struts provides a basic Connection Pool, but user comments suggest that
> > this is not suitable for large-scale, high-traffic applications, and
> > also that it will soon be removed from Struts in favour of a
> > container-managed connection pool
>
> So what will Tomcat Users do? Will Tomcat get a container manages connection
> pool?

http://jakarta.apache.org/tomcat/tomcat-4.0-doc/jndi-resources-howto.html

> What is the reason for removing it form Struts?

That was a hypothetical example of a possible future situation that would
cause the need to change your code.

>
> R.

Craig McClanahan



--
To unsubscribe:   <mailto:[EMAIL PROTECTED]>
For additional commands: <mailto:[EMAIL PROTECTED]>
Troubles with the list: <mailto:[EMAIL PROTECTED]>

Re: Tomcat 4.x and Database Connection Pooling

[Ric Searle]

Not sure - probably a little out of my depth here, but poolman 
(www.codestudio.com), which used to do connection pooling stuff is no 
longer available, and it's author claims that:

"If you are looking for connection and object pooling
mechanisms, they can now be found in application
servers such as JRun, Tomcat and the Jakarta Project,
and other J2EE products and servers."

Which is where my journey started...!

   Ric Searle
   Web Application Developer
   --
   Dialogue Communications Ltd

   http://www.dialogue.co.uk
   +44 (0) 114 221 0307


On Wednesday, April 10, 2002, at 04:18  pm, rainer jünger wrote:

> Hi Ric,
>
>> Struts provides a basic Connection Pool, but user comments suggest that
>> this is not suitable for large-scale, high-traffic applications, and
>> also that it will soon be removed from Struts in favour of a
>> container-managed connection pool
>
> So what will Tomcat Users do? Will Tomcat get a container manages 
> connection
> pool?
> What is the reason for removing it form Struts?
>
> R.
>


--
To unsubscribe:   
For additional commands: 
Troubles with the list: 

Re: Tomcat 4.x and Database Connection Pooling

[rainer jünger]

Hi Ric,

> Struts provides a basic Connection Pool, but user comments suggest that
> this is not suitable for large-scale, high-traffic applications, and
> also that it will soon be removed from Struts in favour of a
> container-managed connection pool

So what will Tomcat Users do? Will Tomcat get a container manages connection
pool?
What is the reason for removing it form Struts?

R.


--
To unsubscribe:   
For additional commands: 
Troubles with the list: 

Re: Tomcat 4.x and Database Connection Pooling

[Ric Searle]

Performance isn't so important as future-proofing - I don't want to have 
to re-write the db interface when struts drops it's connection pool 
provision, for example.

I believe that mm.mysql does support pooling, although I take your point 
that others may not.  I can't see us moving away from MySQL at the 
moment, so that's fine.

My use of the database is really quite simple, so I'm sure that commons 
would be fine, but at the moment I don't know where to start integrating 
it with my Struts project.  Does the container manage the pool (i.e. 
some server.xml configuration needed)? Or do I instantiate and manage 
the pool from within my application, and if so, how?

Regards,

   Ric Searle
   Web Application Developer
   --
   Dialogue Communications Ltd

   http://www.dialogue.co.uk
   +44 (0) 114 221 0307


On Wednesday, April 10, 2002, at 02:44  pm, peter lin wrote:

>
> if performance is a critical requirement, than I would suggest writing a
> custom bean specific to the jdbc driver you intend to use. If Jakarta
> common provides all the features you need, than go with it.
>
> If your application needs to support multiple databases and jdbc
> drivers, be warned that not all jdbc drivers implement pooling, nor do
> they implement it the same way. In particular, jdbc drivers for
> SQLserver vary significantly in implementation, so doing real world
> benchmarks of each driver is critical.
>
> If commons doesn't provide the features you need, like scrollable
> resultsets, you may want to implement jdbc 2.0 compliant pooling driver
> using javax.sql api.
>
> good luck
>
> peter lin
>
>



--
To unsubscribe:   
For additional commands: 
Troubles with the list: 

Re: Tomcat 4.x and Database Connection Pooling

[peter lin]

if performance is a critical requirement, than I would suggest writing a
custom bean specific to the jdbc driver you intend to use. If Jakarta
common provides all the features you need, than go with it.

If your application needs to support multiple databases and jdbc
drivers, be warned that not all jdbc drivers implement pooling, nor do
they implement it the same way. In particular, jdbc drivers for
SQLserver vary significantly in implementation, so doing real world
benchmarks of each driver is critical.

If commons doesn't provide the features you need, like scrollable
resultsets, you may want to implement jdbc 2.0 compliant pooling driver
using javax.sql api.

good luck

peter lin



Ric Searle wrote:
> 
> Hi,
> 
> I'm developing a web application using the Struts framework, running on
> Tomcat 4.0.3, from which I need to access a MySQL database.  I've read
> various mailing lists etc looking for the best way to achieve this, but
> not had much luck.
> 
> Struts provides a basic Connection Pool, but user comments suggest that
> this is not suitable for large-scale, high-traffic applications, and
> also that it will soon be removed from Struts in favour of a
> container-managed connection pool.  I've found references to
> DbConnectionBroker and Jakarta's commons-dbcp module.  It seems to make
> sense to use the latter, to keep the entire project neatly under the
> Jakarta project, but I'd appreciate comments on either.
> 
> I'm fairly new to Tomcat (and Servlets), and I can't find any simple
> examples of how to use one of these connection pools.  I suspect that I
> need to add something to my server.xml, and instantiate the pool in the
> servlet's init() method.  It would be greatly appreciated if someone
> could provide some simple instructions to get me started - sample code
> would be fantastic.
> 
> I hope to write about my experiences with this once I understand it -
> there seems to be a need for documentation in this area.
> 
> Regards,
> 
>Ric Searle
>Web Application Developer
>--
>Dialogue Communications Ltd
> 
>http://www.dialogue.co.uk
>+44 (0) 114 221 0307
> 
> --
> To unsubscribe:   
> For additional commands: 
> Troubles with the list: 

--
To unsubscribe:   
For additional commands: 
Troubles with the list: