Have you asked/searched WebLogic areas to see if there's such a switch? It
seems quite shortsighted that any pool design would assume all connections
handed out will eventually make it back on their own.

I wouldn't think that a connection being stored somewhere or not would
affect the ability for it to be put back in the pool; the only thing that
would put it back would be it's close() method. And I thought the definition
of a data source's connection's close() method was to put the connection
back in the pool; all the documentation and tutorials I've seen say this.

-Stevers 


-----Original Message-----
From: Stefan Frank [mailto:[EMAIL PROTECTED]]
Sent: Thursday, November 22, 2001 4:36 AM
To: Tag Libraries Users List
Subject: AW: DBTags in a production enviroment??! ConnectionPool running
out


I'm currently looking for exactly this switch in the ConnectionPool: Alas,
there is no such thing in Weblogic6.1. To me it looks like the Connection is
stored somewhere (in the Session?! Applicationwide?!) and it doesn't matter
wether you close it or not. Does anybody know, where it is stored?! Will it
help to set the connection to null manually?!

> -----Ursprüngliche Nachricht-----
> Von: Steve Johnson-Evers [mailto:[EMAIL PROTECTED]]
> Gesendet: Mittwoch, 21. November 2001 17:53
> An: 'Tag Libraries Users List'; 'Stefan Frank'
> Betreff: RE: DBTags in a production enviroment??! ConnectionPool running
> out
>
>
> This doesn't really answer your question, but can't you configure your
> connection pool to repossess a connection if it hasn't been
> returned after a
> certain amount of time? Certainly the majority of the connections are
> getting returned so we're dealing with some exception situation.
>
> -Stevers
>
> P.S. I've just started with these things so I don't know much about them.
>
>
> -----Original Message-----
> From: Stefan Frank [mailto:[EMAIL PROTECTED]]
> Sent: Wednesday, November 21, 2001 5:20 AM
> To: 'Taglibs-User
> Subject: DBTags in a production enviroment??! ConnectionPool running out
>
>
> Hi folks,
>
> I post this once again, as we are still in serious trouble with our
> application that relies on the dbtags. We have the following code, that
> appeared to be working until we found out, that the code drains our
> connection pool:
>
>
> <sql:connection id="conn" jndiName="jspDataSource"/>
> <sql:statement id="stmt1" conn="conn">
>
> <sql:query>
>
> SELECT internet.statistik.name,
>
> internet.statistik.siege, internet.statistik.p2,
>
> internet.statistik.p3, internet.statistik.p4,
>
> internet.statistik.p5, internet.statistik.starts,
>
> internet.statistik.gewinnsumme,
>
> internet.statistik.siegprozent,
>
> internet.statistik.gw_pro_start,
>
> internet.statistik.gewinn_max, internet.statistik.id,
>
> internet.statistik.jahr, internet.statistik.stat_art,
>
> internet.statistik.rart, internet.statistik.starter,
>
> internet.statistik.sieger, internet.statistik.zue_pr,
>
> internet.statistik.stand,
>
> internet.statistik.id
>
> FROM internet.statistik
>
> WHERE internet.statistik.gewinnsumme IS NOT NULL
>
> AND internet.statistik.rart = 'G'
>
> AND internet.statistik.jahr = 2001
>
> AND internet.statistik.stat_art = 2
>
>
> ORDER BY internet.statistik.gewinnsumme desc,
>
> internet.statistik.gw_pro_start
>
>
> </sql:query>
>
> <%-- loop through the rows of your query --%>
>                                                                       <%
> int i=0; %>
>
>
> <sql:resultSet id="jockeys">
>
> <tr>
>
> <td align=right><div class="tabellentext_re"><sql:rowCount
> /></div></td>
>
> <td><div class="tabellentext"><a
> href='/dvrWebApp/htdocs/aktive/nonsecure/renndaten/personDetail.js
> p?PERSONID
> =<sql:getColumn position="20"/>' class="link"><sql:getColumn
> position="1"/></a></div></td>
>
> <td align=right><div class="tabellentext_re"><sql:getColumn
> position="2"/></div></td>
>
> <td align=right><div class="tabellentext_re"><sql:getColumn
> position="3"/></div></td>
>
> <td align=right><div class="tabellentext_re"><sql:getColumn
> position="4"/></div></td>
>
> <td align=right><div class="tabellentext_re"><sql:getColumn
> position="5"/></div></td>
>
> <td align=right><div class="tabellentext_re"><sql:getColumn
> position="6"/></div></td>
>
> <td align=right><div class="tabellentext_re"><sql:getColumn
> position="7"/></div></td>
>
> <td align=right><div class="tabellentext_re"><sql:getNumber
> position="8" format="NUMBER" locale="DE"/></div></td>
>
> <td align=right><div class="tabellentext_re"><sql:getColumn
> position="9"/></div></td>
>
> </tr>
>
> </sql:resultSet>
>                                                          </sql:statement>
> </table><img src="/dvrWebApp/htdocs/images/dot_trans.gif" width="1"
> height="10" alt="" border="0"><br>
>
> <sql:closeConnection conn="conn"/>
>
>
> Is there something I am missing?! What happens in a case of failure?! Is
> there any way to wrap up the close in a finally-block?! We are using
> weblogic 6.1 and an oracle Database. Does anybody out there use
> the dtbatgs
> on weblogic??! This problem makes the dbtags completely unusable in a
> production enviroment, as we have to restart the server every one or two
> days to release the Connection. We are rather desparate right
> know: This bug
> has appeared when most of the application is finished using dbtags - If we
> can't fix this we have to throw out dbtags and rewrite the whole
> thing. ANY
> HELP VERY VERY APPRECIATED!!!!
>
> Greetings
> Stefan
>
>
>
> ---
> vierundsechzig.de
> friedensallee 7-9
> 22765 hamburg
> telefon +49 (040) 306033 -43
> telefax +49 (040) 306033 -64
>
> http://www.vierundsechzig.de
> mailto:[EMAIL PROTECTED]
>
>
> --
> 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]>
>


--
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]>

Reply via email to