we should run this past other core devels and see their opinions.
personally, if i knew i had a long running process i would spin off a new thread, do it there, then notify the user when it is complete. i know that is not always doable, just a suggestion.
-Igor
On 6/21/06, Matej Knopp <[EMAIL PROTECTED]> wrote:
If there was something like
RequestCycle.lockSession()
RequestCycle.unlockSession()
where in my onClock handler I could call
RequestCycle.get().unlockSession()
--do-my-stuff-and-don't-touch-the-session!
RequestCycle.get().lockSession()
I know this adds responsibility to the developer, but this is only for
corner cases.
-Matej
Matej Knopp wrote:
> Sorry, i'm lost. How is overriding getlock() supposed to help me? I need
> to lock the session, but not for the whole request. Just for a part
> before the db call and the part after.
>
> -Matej
>
> Igor Vaynberg wrote:
>> in that case we sort of already have a mechanism for that, request
>> target has a getlock() which you can override and return something other
>> then session, just need a way to encode a url so it is resolved to your
>> own target
>>
>> -Igor
>>
>>
>>
>>
>> On 6/21/06, *Matej Knopp* <[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>> wrote:
>>
>> Well, it would be your responsibility not to touch application or
>> session if the mutex is unlocked. This is not something an average joe
>> would do in every link handler. You would do that only right before a
>> long db operation and lock it right after it.
>>
>> I'm not looking for perfect solution. I'm looking for one that works. A
>> solution when the application stops responding until session expires is
>> not perfect either.
>>
>> -Matej
>>
>> Igor Vaynberg wrote:
>> > but you wouldnt want to unlock the mutex, thats kinda the whole
>> point!
>> > what if both pages access session object? or application object?
>> now you
>> > have to start worrying about concurrency on those. the advantage of
>> > letting only one page request through at a time is that users
>> dont have
>> > to think about concurrency, if we dont do that the programming model
>> > becomes much more complicated. it has its draw backs for sure, but i
>> > dont think there is a perfect solution here.
>> >
>> > -Igor
>> >
>> >
>> >
>> > On 6/21/06, *Matej Knopp* <[EMAIL PROTECTED] <mailto: [EMAIL PROTECTED]>
>> <mailto: [EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>>> wrote:
>> >
>> > Igor Vaynberg wrote:
>> > > not unless all page targets return the same mutex instance :)
>> > The mutex would be stored in session of course :)
>> > >
>> > > the point is that only a single page is processed at a time
>> > because of
>> > > pagemap, etc. although i dont really know if the pagemap is
>> > affected all
>> > > that much in 2.0.
>> > >
>> > > but even then, lets say i double click a link really fast,
>> i get two
>> > > different instances of pagetarget that are going to do
>> processing
>> > on the
>> > > same page instance, so once again both of those page
>> targets have to
>> > > return the same mutex instance. dont know how we are going
>> to do
>> > that or
>> > > if it will be simpler/better then locking session.
>> > I don't think it would be simpler. But it would be better in
>> a way that
>> > if you have an action that takes very long, you can "unlock"
>> the mutex
>> > in you link handler, let other requests process, and after
>> you are
>> > done,
>> > you lock the session again.
>> > >
>> > > the thing about the db locking up is that it should have some
>> > sort of a
>> > > timeout that throws an error, and the sync block should
>> then be
>> > broken.
>> > > that doesnt happen? sounds like more of a fault in your app?
>> > maybe we
>> > > should build a timeout for our sync block.
>> > Well, the db can either lock up, or it really takes that long
>> to get the
>> > data (complicated statistics, reports, etc). In the meanwhile
>> user would
>> > like to work with the rest of the application but he can't.
>> >
>> > -Matej
>> > >
>> > > -Igor
>> > >
>> > >
>> > > On 6/21/06, *Matej Knopp* <[EMAIL PROTECTED]
>> <mailto:[EMAIL PROTECTED] > <mailto:[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>>
>> > <mailto: [EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>
>> <mailto:[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>>>> wrote:
>> > >
>> > > Hi,
>> > >
>> > > we have a problem with session locking. Sometimes, the
>> underlying
>> > > database just hangs and the response is not processed
>> > properly. The
>> > > problem is that HttpSession remains locked.
>> > >
>> > > Wouldn't it be possible to replace the current locking
>> mechanism
>> > > ( synchronized(lock) { doEverything() } )
>> > >
>> > > with something that would behave more like a mutex?
>> > >
>> > > e.g.
>> > >
>> > > Mutext mutex = getRequestTarget().getMutex();
>> > >
>> > > mutex.lock();
>> > > processRequest();
>> > > mutex.unlock ();
>> > >
>> > > and the code running the operation could look like
>> > >
>> > >
>> RequestCycle().get().getReqeustTarget().getMutex().unlock();
>> > > doMySloooowOperation();
>> > >
>> RequestCycle().get().getReqeustTarget().getMutex().lock();
>> > >
>> > > -Matej
>> > >
>> > >
>> > > _______________________________________________
>> > > Wicket-develop mailing list
>> > > Wicket-develop@lists.sourceforge.net
>> <mailto:Wicket-develop@lists.sourceforge.net>
>> > <mailto:Wicket-develop@lists.sourceforge.net
>> <mailto:Wicket-develop@lists.sourceforge.net >>
>> > > <mailto: Wicket-develop@lists.sourceforge.net
>> <mailto: Wicket-develop@lists.sourceforge.net>
>> > <mailto:Wicket-develop@lists.sourceforge.net
>> <mailto: Wicket-develop@lists.sourceforge.net>>>
>> > >
>> https://lists.sourceforge.net/lists/listinfo/wicket-develop
>> > < https://lists.sourceforge.net/lists/listinfo/wicket-develop>
>> > >
>> > >
>> > >
>> > >
>> >
>> ------------------------------------------------------------------------
>>
>> > >
>> > > _______________________________________________
>> > > Wicket-develop mailing list
>> > > Wicket-develop@lists.sourceforge.net
>> <mailto:Wicket-develop@lists.sourceforge.net>
>> > <mailto: Wicket-develop@lists.sourceforge.net
>> <mailto:Wicket-develop@lists.sourceforge.net>>
>> > >
>> https://lists.sourceforge.net/lists/listinfo/wicket-develop
>> <https://lists.sourceforge.net/lists/listinfo/wicket-develop>
>> >
>> >
>> >
>> > _______________________________________________
>> > Wicket-develop mailing list
>> > Wicket-develop@lists.sourceforge.net
>> <mailto:Wicket-develop@lists.sourceforge.net>
>> > <mailto:Wicket-develop@lists.sourceforge.net
>> <mailto:Wicket-develop@lists.sourceforge.net >>
>> > https://lists.sourceforge.net/lists/listinfo/wicket-develop
>> < https://lists.sourceforge.net/lists/listinfo/wicket-develop>
>> > <https://lists.sourceforge.net/lists/listinfo/wicket-develop >
>> >
>> >
>> >
>> >
>> ------------------------------------------------------------------------
>>
>> >
>> > _______________________________________________
>> > Wicket-develop mailing list
>> > Wicket-develop@lists.sourceforge.net
>> <mailto:Wicket-develop@lists.sourceforge.net>
>> > https://lists.sourceforge.net/lists/listinfo/wicket-develop
>>
>>
>>
>> _______________________________________________
>> Wicket-develop mailing list
>> Wicket-develop@lists.sourceforge.net
>> <mailto:Wicket-develop@lists.sourceforge.net>
>> https://lists.sourceforge.net/lists/listinfo/wicket-develop
>>
>>
>>
>> ------------------------------------------------------------------------
>>
>> _______________________________________________
>> Wicket-develop mailing list
>> Wicket-develop@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/wicket-develop
>
>
>
> _______________________________________________
> Wicket-develop mailing list
> Wicket-develop@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wicket-develop
>
_______________________________________________
Wicket-develop mailing list
Wicket-develop@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-develop
_______________________________________________ Wicket-develop mailing list Wicket-develop@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-develop
