You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@wicket.apache.org by "Thomas Heigl (Jira)" <ji...@apache.org> on 2020/02/27 11:03:00 UTC
[jira] [Updated] (WICKET-6751) Support creating custom page access
synchronization strategies
[ https://issues.apache.org/jira/browse/WICKET-6751?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Thomas Heigl updated WICKET-6751:
---------------------------------
Description:
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=M9Q@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.
was:
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=M9Q@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.
> 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=M9Q@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)