[ 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 reside in the container memory and are not re-created 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. 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 reside in the container memory and are not (de)serialized 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. > 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 reside in the container memory and are not > re-created 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)