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