[ 
https://issues.apache.org/jira/browse/WICKET-6177?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15373508#comment-15373508
 ] 

Martin Grigorov commented on WICKET-6177:
-----------------------------------------

Hi,

I think your code should work.

It won't be possible to use the Session's PageAccessSynchronizer even if it was 
possible to get a reference to it because it doesn't keep track of the number 
of locks per pageId.
So Wicket will lock the page in the begin of the request cycle, then your logic 
will call lockPage() again and then fork the serialization in a new thread. The 
previous thread will continue by committing the request, i.e. will call 
unlockAllPages(). At the end of the serialization your logic will call again 
unlockAllPages() but this will do nothing. If in the meantime another request 
asks for this page by id then it will use an older version of it, if there is 
such, i.e. there was an Ajax request for it before.

So I see two solutions:
- use a second PageAccessSynchronizer as you did it
- add logic to PageAccessSynchronizer to count the locks and unlocks

I'd prefer the first solution because the second adds complexity that is not 
really needed by 99% of the apps.

> Blocking page serialization
> ---------------------------
>
>                 Key: WICKET-6177
>                 URL: https://issues.apache.org/jira/browse/WICKET-6177
>             Project: Wicket
>          Issue Type: Bug
>          Components: wicket
>    Affects Versions: 7.4.0
>         Environment: any
>            Reporter: Martin Makundi
>              Labels: serialization
>         Attachments: 6177.tgz, Wicket_Quickstart_7.zip
>
>   Original Estimate: 168h
>  Remaining Estimate: 168h
>
> We have a performance issue with our Wicket app, page serialization causes 
> inconvenience to user because PageStoreManager.storeTouchedPages() blocks the 
> request until pageSerializer.serialize(page) has been handled.
> Could this be solved by serializing the page in a separate thread and let the 
> request complete?
> The problem we have is that user is making quick small ajax modifications to 
> the page but serialization + network latency makes the delay very 
> inconvenient. If serialization could be done in separate thread, user would 
> feel only the network delay which is bearable.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Reply via email to