[
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 or are clustered by the
container 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 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.
> 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 or are clustered by
> the container 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)
