[
https://issues.apache.org/jira/browse/WICKET-6751?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17047529#comment-17047529
]
Thomas Heigl commented on WICKET-6751:
--------------------------------------
I created a PR with my proposed changes:
https://github.com/apache/wicket/pull/411
> Support creating custom page access synchronization strategies
> --------------------------------------------------------------
>
> Key: WICKET-6751
> URL: https://issues.apache.org/jira/browse/WICKET-6751
> Project: Wicket
> Issue Type: Task
> Components: wicket-core
> Affects Versions: 8.7.0, 9.0.0-M4
> Reporter: Thomas Heigl
> Priority: Major
>
> While moving from a single server setup to a distributed environment with
> session management provided by Spring Session, I discovered that the current
> implementation of {{PageAccessSynchronizer}} does not work in that scenario.
> It assumes that sessions are global objects and not loaded from an external
> source for each request.
> See my original post to the users mailing list:
> [http://mail-archives.apache.org/mod_mbox/wicket-users/202002.mbox/%3cCANtfzo5+YTBFzyP-U_dVjSrRu8xgv1qj4ozAWxDAbwVnF5=m...@mail.gmail.com%3e]
> Implementing a custom access synchronizer that stores locks in a static
> variable or in the application solves these issues. But providing a custom
> implementation is very cumbersome at the moment. Users have to override all
> concrete methods in the base class and completely duplicate the {{PageLock}}
> class because {{waitForRelease}} and {{markReleased}} have package visibility.
>
> I suggest to make these two methods in {{PageLock}} public so the class can
> be reused and extract all the locking logic into an {{ILockManager}} with 3
> methods: {{lockPage}}, {{unlockPage}}, and {{unlockAllPages}}. The default
> lock manager could hold the session-scoped locks collection and custom
> implementations could provide their own locking mechanism.
>
> These changes should be quite straight forward. I can provide a PR if
> necessary.
>
> Since the changes required are not entirely backwards compatible, I guess
> that the PR target would be Wicket 9.
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
