[
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
(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.
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 application 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
> (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.
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
