RE: Singleton vs ServletContext

[Jose Galiana <jg...@epi.es>]

Hi, Adam

Can you send me a copy of your code?

Thanks
Jose Galiana
Recursos en la Red, S.L.U

-----Mensaje original-----
De: Damien VIEL [mailto:damien@studioclick.fr]
Enviado el: miércoles, 24 de abril de 2002 11:59
Para: Struts Users Mailing List
CC: akipnis@jamdat.com
Asunto: Re: Singleton vs ServletContext


Yes,
Please send me a copy

Thanks

Dams
damien@studioclick.fr

----- Original Message -----
From: "Kipnis, Adam" <AK...@jamdat.com>
To: "'Struts Users Mailing List'" <st...@jakarta.apache.org>
Sent: Tuesday, April 23, 2002 7:37 PM
Subject: RE: Singleton vs ServletContext


> I wouldn't recommend Poolman since I have found it to be pretty
problematic.
> As for the Singleton vs Servlet approach, I think that's really up to
> personal preference. If you put your connection pool logic inside a
servlet
> and have that servlet load on startup, you're not really that much
different
> than a standard singleton. Since there are usually more uses for an
> application level service other than a connection pool (ie, a global level
> internal data caching system), I wrote a services manager as a servlet
that
> loads all the application level services, including connection pools, on
> start-up based on configuration files. If you like, I can send you a copy
of
> the servlet and associated connection pool.
>
> -Adam Kipnis
> akipnis@jamdat.com
>
>
> -----Original Message-----
> From: Damien VIEL [mailto:damien@studioclick.fr]
> Sent: Tuesday, April 23, 2002 12:20 AM
> To: Struts Users Mailing List
> Subject: Singleton vs ServletContext
>
>
> Hi !!
>
> My question is about the best way to implement a JDBC ConnectionPool for
> Struts.
> I've heard that the one that is already in Struts is not a good choice.
> I've also read many mails about PoolMan.
> In Servlets & JSP book from Marty Hall, he speaks also about Singleton.
>
> What's the easiest way ?
> Has anybody a simple sample ?
>
> Thanks All.
>
> Best
>
> Dams
>
>
> --
> To unsubscribe, e-mail:
<ma...@jakarta.apache.org>
> For additional commands, e-mail:
<ma...@jakarta.apache.org>
>
>


--
To unsubscribe, e-mail:
<ma...@jakarta.apache.org>
For additional commands, e-mail:
<ma...@jakarta.apache.org>



--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>