I haven't had much of a chance to look into this.  But do a search in the
code for 'java.sql.Connection'.  This is probably the culprit.

Based on what I've seen in the code, I would look there before I started
worrying about Hibernate.

>From what I've seen, we're bypassing Hibernate in the reports functionality
as well as other places.  So, Connection management is most likely done
explicitly there.

If you're interested in gathering Hibernate statistics as well, I added a
rough implementation of the StatisticsService in the MifosTestCase class.
This keeps track of open connections and other very useful statistics (like
the number of commits and such).

Thanks for all the input everyone!  :)
-Tom

On Nov 16, 2007 10:16 AM, Sam Lee <[EMAIL PROTECTED]> wrote:

> On Nov 15, 2007 9:50 PM, Amy Bensinger (Contractor)
> <[EMAIL PROTECTED]> wrote:
> > What might also be interesting is if any DBA-types have workaround
> > suggestions/scripts while the longer term solutions are considered?
> >
> >
>
> Workarounds: an ugly but fairly effective workaround is to
> periodically force the application (mifos in this case) closes the
> connections.
>
> Option 1: If a connection pool is used, one can also try to
> reconfigure the connection pool to force connections to be closed
> after certain amount of time. E.g., tricks one can use with c3p0:
>
>
> http://www.mchange.com/projects/c3p0/index.html#configuring_to_debug_and_workaround_broken_clients
>
>
> Option 2: the most brute-force way would be to have a script to
> periodically restarting the app server (in off peak hours, more leeway
> if the deployment has multiple servers so that the restart can be
> staggered).
>
> To those who knows mifos config better: is the db connection
> properties all set in the confi/hibernate.properties and the
> hibernate.cfg.xml  (somewhere under the source tree) (at least for the
> GK deployment)?  If so, I could take a stab to figure out if we could
> have it reconfigured to use c3p0 connection pool to timeout the
> connections.
>
> Let me know.
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2005.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
>
-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/

Reply via email to