I'm using dbcp, as per below. I'll try switching over to c3p0 and see if that helps.
<bean id="dataSourceOracle" class="org.apache.commons.dbcp.BasicDataSource" destroy-method="close"> <property name="driverClassName" value="${jdbc.oracle.driver}"/> <property name="url" value="${jdbc.oracle.url}"/> <property name="username" value="${jdbc.oracle.username}"/> <property name="password" value="${jdbc.oracle.password}"/> </bean> On Tue, Aug 25, 2009 at 2:25 PM, Martijn Dashorst < martijn.dasho...@gmail.com> wrote: > Do you use a connection pool? e.g. datasource definition in your > container, dbcp or c3p0? If not, use one. > > Martijn > > On Tue, Aug 25, 2009 at 11:10 PM, Dane Laverty<danelave...@gmail.com> > wrote: > > I think I've discovered the source of the problem, but not the solution. > On > > a normal page request, the console output says: > > > > DEBUG - log - REQUEST /post-job on > > org.mortbay.jetty.httpconnect...@1b9db06 ... > > DEBUG - ConnectionManager - opening JDBC connection > > DEBUG - SQL - select > > jobcategor0_.job_category_id... > > > > And everything goes normally from there. But on double-clicking the link, > > the console says: > > > > DEBUG - log - REQUEST /post-job on > > org.mortbay.jetty.httpconnect...@1b9db06 ... > > DEBUG - ConnectionManager - opening JDBC connection > > DEBUG - log - REQUEST /post-job on > > org.mortbay.jetty.httpconnect...@a78af0 ... > > DEBUG - ConnectionManager - opening JDBC connection > > > > And then the application freezes. Apparently it is trying to open a > second > > JDBC connection before the first one closed, and something doesn't like > > that. I'm not sure where to start looking to solve this -- any > suggestions? > > > > thanks again, > > > > Dane > > > > > > > > On Tue, Aug 25, 2009 at 1:22 PM, Dane Laverty <danelave...@gmail.com> > wrote: > > > >> Progress is being made. Thanks again for your suggestion, Martijn. I > >> discovered this thread ( > >> > http://www.nabble.com/Storing-user-entity-in-session--td22113666.html#a22113666) > where you discussed putting the user in the RequestCycle in some more > >> detail. That helped me rebuild my RequestCycle [1]. > >> > >> The new RequestCycle solved the LazyInitializationException, but created > a > >> new problem. The application runs fine, but if I click a link twice in > rapid > >> succession, the application hangs for all users until I restart the > server. > >> This is kind of a major problem :) I've pasted the server output below > [2]. > >> The console stops on the line "DEBUG - ConnectionManager - opening JDBC > >> connection" for a couple minutes, then throws the > "java.net.SocketException: > >> Connection reset" stack trace. > >> > >> Googling "java.net.SocketException: Connection reset" shows that the > error > >> is connected to a wide array of issues. Has anyone here run into the > problem > >> before? And if so, how did you solve it? > >> > >> thanks, > >> > >> Dane > >> > >> ------- > >> > >> [1] - public class WicketRequestCycle extends WebRequestCycle implements > >> Serializable { > >> > >> EntityModel<UserInfo> userInfoModel; > >> ... > >> public UserInfo getUserInfo() { > >> if (userInfoModel != null) return userInfoModel.getObject(); > >> UserInfo userInfo = WicketSession.get().generateUserInfo(); > >> if (userInfo == null) return null; > >> userInfoModel = new EntityModel<UserInfo>(userInfo); > >> return userInfoModel.getObject(); > >> } > >> > >> @Override > >> public void detach() { > >> super.detach(); > >> if (userInfoModel != null) > >> userInfoModel.detach(); > >> } > >> } > >> > >> > >> [2] - TRACE - SessionImpl - closing session > >> TRACE - ConnectionManager - connection already null in cleanup > : > >> no action > >> DEBUG - log - RESPONSE /images/lotus.png 200 > >> DEBUG - log - REQUEST /login on > >> org.mortbay.jetty.httpconnect...@7d0f44 > >> DEBUG - log - Got Session ID 1haooq2s24av1 from > >> cookie > >> DEBUG - log - > >> sessionmanager=org.mortbay.jetty.servlet.hashsessionmana...@3411a > >> DEBUG - log - > >> > session=org.mortbay.jetty.servlet.HashSessionManager$Session:1haooq2s24...@18296160 > >> DEBUG - log - servlet=default > >> DEBUG - log - > >> chain=open.hibernate.session.in.view->wicket.careerconnect->default > >> DEBUG - log - servelet holder=default > >> DEBUG - log - call filter > >> open.hibernate.session.in.view > >> DEBUG - OpenSessionInViewFilter - Using SessionFactory > 'sessionFactory' > >> for OpenSessionInViewFilter > >> DEBUG - DefaultListableBeanFactory - Returning cached instance of > singleton > >> bean 'sessionFactory' > >> DEBUG - OpenSessionInViewFilter - Opening single Hibernate Session in > >> OpenSessionInViewFilter > >> DEBUG - SessionFactoryUtils - Opening Hibernate Session > >> DEBUG - SessionImpl - opened session at timestamp: > >> 5125043523203072 > >> TRACE - SessionImpl - setting flush mode to: NEVER > >> DEBUG - tionSynchronizationManager - Bound value > >> [org.springframework.orm.hibernate3.sessionhol...@117a49c] for key > >> [org.hibernate.impl.sessionfactoryi...@737f58] to thread [btpool0-4 - > >> > /login;jsessionid=1haooq2s24av1?wicket:interface=:0:loginForm::IFormSubmitListener::] > >> DEBUG - log - call filter wicket.careerconnect > >> DEBUG - SessionFactoryUtils - Opening Hibernate Session > >> DEBUG - SessionImpl - opened session at timestamp: > >> 5125043523203073 > >> TRACE - QueryPlanCache - located HQL query plan in cache ( > >> select employerInfo from EmployerInfo as employerInfo inner join > >> employerInfo.contactPoints as contactPoints where > contactPoints.contactInfo > >> = ? and employerInfo.password = md5_digest(?)) > >> TRACE - QueryPlanCache - located HQL query plan in cache ( > >> select employerInfo from EmployerInfo as employerInfo inner join > >> employerInfo.contactPoints as contactPoints where > contactPoints.contactInfo > >> = ? and employerInfo.password = md5_digest(?)) > >> TRACE - HQLQueryPlan - find: select employerInfo from > >> EmployerInfo as employerInfo inner join employerInfo.contactPoints as > >> contactPoints where contactPoints.contactInfo = ? and > >> employerInfo.password = md5_digest(?) > >> TRACE - QueryParameters - parameters: [dane, asdf] > >> TRACE - QueryParameters - named parameters: {} > >> DEBUG - AbstractBatcher - about to open PreparedStatement > (open > >> PreparedStatements: 0, globally: 4) > >> DEBUG - ConnectionManager - opening JDBC connection > >> DEBUG - log - EXCEPTION > >> java.net.SocketException: Connection reset > >> at java.net.SocketInputStream.read(SocketInputStream.java:168) > >> at org.mortbay.io.ByteArrayBuffer.readFrom(ByteArrayBuffer.java:172) > >> at org.mortbay.io.bio.StreamEndPoint.fill(StreamEndPoint.java:107) > >> at > >> > org.mortbay.jetty.bio.SocketConnector$Connection.fill(SocketConnector.java:196) > >> at org.mortbay.jetty.HttpParser.parseNext(HttpParser.java:279) > >> at org.mortbay.jetty.HttpParser.parseAvailable(HttpParser.java:204) > >> at org.mortbay.jetty.HttpConnection.handle(HttpConnection.java:379) > >> at > >> > org.mortbay.jetty.bio.SocketConnector$Connection.run(SocketConnector.java:226) > >> at > >> > org.mortbay.thread.BoundedThreadPool$PoolThread.run(BoundedThreadPool.java:442) > >> DEBUG - log - EOF > >> > >> > >> > >> On Mon, Aug 24, 2009 at 6:06 PM, Dane Laverty <danelave...@gmail.com > >wrote: > >> > >>> I took your advice and added a UserInfo variable to the RequestCycle > [1]. > >>> Now my pages look for the UserInfo in the RequestCycle. If it's null, > the > >>> RequestCycle loads it from the ID in Session [2]. However, I still get > the > >>> LazyInitializationException when a page wants to access a collection > from > >>> userInfo [3], presumably because the Hibernate session was closed after > the > >>> Session loads the UserInfo. I thought that the OpenSessionInViewFilter > was > >>> supposed to keep the session open during the entire request, but > apparently > >>> I'm using it wrong. > >>> > >>> [1] - public class WicketRequestCycle extends WebRequestCycle > implements > >>> Serializable { > >>> > >>> UserInfo userInfo; > >>> ... > >>> public UserInfo getUserInfo() { > >>> if (userInfo != null) return userInfo; > >>> userInfo = WicketSession.get().generateUserInfo(); > >>> return userInfo; > >>> } > >>> } > >>> > >>> > >>> [2] - public class WicketSession extends AuthenticatedWebSession { > >>> > >>> @SpringBean(name = "userInfoDao") > >>> private UserInfoDao userInfoDao; > >>> > >>> private Long userInfoID; > >>> ... > >>> public UserInfo generateUserInfo() { > >>> if (userInfoID == null) return null; > >>> return personInfoDao.load(personInfoId, personInfoClass); > >>> } > >>> } > >>> > >>> [3] - public class UserRolesAuthorizer implements IRoleCheckingStrategy > >>> { > >>> public boolean hasAnyRole(Roles roles) > >>> { > >>> PersonInfo personInfo = > WicketRequestCycle.get().getPersonInfo(); > >>> // THIS NEXT LINE THROWS THE ERROR, since it's trying to load > >>> BasicUser > >>> return userInfo.getBasicUser().hasAnyRole(roles); > >>> } > >>> > >>> } > >>> > >>> > >>> On Mon, Aug 24, 2009 at 2:12 PM, Martijn Dashorst < > >>> martijn.dasho...@gmail.com> wrote: > >>> > >>>> Don't put the models in your session! Session access is not guaranteed > >>>> to be confined to a single thread - multi window support, resources > >>>> and such all attach the session to their own threads, making the > >>>> session non-thread safe. > >>>> > >>>> Best option is to put the ID of your entities in your session object, > >>>> and store the entities in your request cycle for request processing. > >>>> > >>>> Martijn > >>>> > >>>> On Mon, Aug 24, 2009 at 9:21 PM, Dane Laverty<danelave...@gmail.com> > >>>> wrote: > >>>> > I understand that a Hibernate-generated object needs to be kept in a > >>>> > LoadableDetachableModel in order to avoid errors across requests. I > >>>> also > >>>> > understand that a LDM has to belong to a component in order for its > >>>> detach > >>>> > to be called at the end of a request. So what should I do with > >>>> > Hibernate-generated objects that live in the session, specifically a > >>>> > UserInfo object? Since the session doesn't have a model, how do I > >>>> inform > >>>> > Wicket to detach these models after each request? > >>>> > > >>>> > thanks, > >>>> > > >>>> > Dane > >>>> > > >>>> > >>>> > >>>> > >>>> -- > >>>> Become a Wicket expert, learn from the best: > http://wicketinaction.com > >>>> Apache Wicket 1.4 increases type safety for web applications > >>>> Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.4.0 > >>>> > >>>> --------------------------------------------------------------------- > >>>> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org > >>>> For additional commands, e-mail: users-h...@wicket.apache.org > >>>> > >>>> > >>> > >> > > > > > > -- > Become a Wicket expert, learn from the best: http://wicketinaction.com > Apache Wicket 1.4 increases type safety for web applications > Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.4.0 > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org > For additional commands, e-mail: users-h...@wicket.apache.org > >