wicket-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Guillaume Smet <guillaume.s...@gmail.com>
Subject Re: Lock timeout per page class
Date Fri, 24 Oct 2014 07:11:17 GMT
Hi Martin,

Yeah, I thought about that too but I'm not sure of the best place to
build the pageId -> pageClassName map. Any advice about this?

Once I'll get this working, I'll build a PR for the few changes I made
in Wicket (based on what you proposed earlier). Would be nice to have
them in 6.18.

On Fri, Oct 24, 2014 at 8:59 AM, Martin Grigorov <mgrigorov@apache.org> wrote:
> Hi Guillaume,
>
> Sorry for not thinking more carefully about this the first time!
> I'm afraid it is not possible to do it the way I suggested.
> PageAccessSynchronizer is the entry point to start using a page and it
> works only with pageId!
>
> Here is a new hackish approach:
> Store pageId -> pageClassName map in the Session. Then when
> PageAccessSynchronizer is requested to lock a page by id use that id to
> resolve the class name and to decide what timeout to use.
>
> Martin Grigorov
> Wicket Training and Consulting
> https://twitter.com/mtgrigorov
>
> On Thu, Oct 23, 2014 at 5:44 PM, Guillaume Smet <guillaume.smet@gmail.com>
> wrote:
>
>> Hi Martin,
>>
>> On Wed, Oct 22, 2014 at 9:51 AM, Martin Grigorov <mgrigorov@apache.org>
>> wrote:
>> > I'd like to avoid moving the logic that gets the timeout from
>> > Session.PageAccessSynchronizerProvider to PageAccessSynchronizer because
>> > this way it will use Application.get() everytime and most apps don't need
>> > to pay for this.
>> >
>> > A way to make it possible for you is to remove the 'final'
>> > from org.apache.wicket.Session#getPageManager and introduce overridable
>> > PageAccessSynchronizer#getTimeout(). This way you can use your own
>> > PageAccessSynchronizer.
>> > http://pastie.org/9667070
>>
>> After a few experiments, here I am!
>>
>> So, it mostly works: I thought it would be better to add something like:
>> protected IProvider<PageAccessSynchronizer>
>> newPageAccessSynchronizerProvider()
>>     {
>>         return new PageAccessSynchronizerProvider();
>>     }
>> in Session and call it from the constructor instead of removing the
>> final so I did that in my code.
>>
>> It works pretty well BUT I haven't found a way to get the page class
>> in getTimeout without having the risk to trigger a resolvePageInstance
>> which will try to lock and then call getTimeout leading to a wonderful
>> stack overflow exception when dealing with
>> ListenerInterfaceRequestHandler.
>>
>> Obviously (...) what interests me the most is the getTimeout in
>> ListenerInterfaceRequestHandler as it's often actions on buttons which
>> are long to run.
>>
>> Here is what I have in mind for my Session class:
>> https://gist.github.com/gsmet/3b9e2775d25fadcef5ef
>>
>> I must admit that an advice would be welcome as I wouldn't like to
>> have stack overflow errors popping out in weird edge cases.
>>
>> Thanks!
>>
>> --
>> Guillaume
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> For additional commands, e-mail: users-help@wicket.apache.org
>>
>>

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org


Mime
View raw message