The application is using the open-session-in-view pattern which is what makes 
this so troubling to figure out.  



-----Original Message-----
From: Dan Retzlaff [mailto:[email protected]] 
Sent: Wednesday, March 21, 2012 5:44 PM
To: [email protected]
Subject: Re: LDM - correct construction

That sounds like a good strategy. Generally speaking, applications use an 
open-session-in-view pattern which makes it easy to ensure that the Hibernate 
session gets closed. As long as that happens, the (mis)handling of transactions 
shouldn't cause your symptoms.

On Wed, Mar 21, 2012 at 2:31 PM, Jeffrey Schneller < 
[email protected]> wrote:

> My service implementation uses hibernate dao objects which should be 
> managing its own connections via the c3p0 connection pool.  All my 
> service objects and Dao objects are marked as singletons in my Spring 
> applicationContext.xml file.  I don't think any of my transactions are 
> failing as it would most likely throw an exception if the there was a 
> problem performing a transactions and all exceptions are logged (at 
> least I believe they are).
>
> I will most likely put the following c3p0 settings in place and wait 
> to see what comes out of this in production.
>
> c3p0.unreturnedConnectionTimeout=30
> c3p0.debugUnreturnedConnectionStackTraces=true
>
> This should give me a stack trace of what checked out a connection, 
> where that connection hasn't been returned to the pool in 30 seconds.  
> It will be a slight performance hit on production but I should be able 
> to find the problem very quickly.
>
> Thanks.
>
> Jeff
>
> -----Original Message-----
> From: Dan Retzlaff [mailto:[email protected]]
> Sent: Wednesday, March 21, 2012 5:04 PM
> To: [email protected]
> Subject: Re: LDM - correct construction
>
> Jeffrey,
>
> That won't prevent a connection from being released. The LDM holds a 
> reference to the page, and the page has a serializable proxy to the 
> service implementation. No problem there. Injecting the service into 
> the LDM is only an advantage if you want to share it among pages; then 
> the LDM can be static and its page reference goes away.
>
> It sounds like your service implementation may have an issue. Does 
> your service manage its own connections? If so, is it a singleton? 
> Other than that, I'd guess there's a bug in your transaction 
> management such that a transaction gets started but not finished.
>
> HTH,
> Dan
>
> On Wed, Mar 21, 2012 at 1:45 PM, Jeffrey Schneller < 
> [email protected]> wrote:
>
> > Is this the correct construction of a LDM where I need to use a 
> > service bean to access my database?  The IMyService bean  is 
> > injected on the page and passed to the LDM.  Does this make the LDM 
> > hold a reference to the IMyService bean and possibly keep a 
> > connection from being put back into the
> > c3p0 db connection pool?  After some period of time my application 
> > is blocked with all threads waiting on a connection to the db.
> >
> > Should I be injected the IMyService bean into the LDM using the 
> > commented out code.  Thanks for any help.
> >
> > public class MyLDM extends
> > LoadableDetachableModel<com.example.MyObject> {
> >
> >                //@SpringBean
> >                private IMyService service;
> >
> >                private String id;
> >
> >                public MyLDM(String id, IMyService service)       {
> >                                this.id = id;
> >                                this.service = service;
> >                }
> >
> >
> >                //public MyLDM(String id)           {
> >                //            this.id = id;
> >                //}
> >
> >
> >                @Override
> >                protected com.example.MyObject load() { 
> > //InjectorHolder.getInjector().inject(this);
> >                                return service.getMyObject(this.id);
> >                }
> > }
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [email protected]
> For additional commands, e-mail: [email protected]
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to