[
https://issues.apache.org/jira/browse/WICKET-1010?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12530678
]
funkattack edited comment on WICKET-1010 at 9/27/07 3:19 AM:
--------------------------------------------------------------
@Johan
We do nothing no more in session.attach() and detach().
The discussion on the list made it possible to move that logic, of setting
transaction borders, to RequestCycle.onBeginRequest and onEndRequest.
was (Author: funkattack):
@Johan
We do nothing no more in session.attach() and detach().
The discussion on the list made it possible to moved that logic, of setting
transaction borders, to RequestCycle.onBeginRequest and onEndRequest.
> Contract of Session.attach() and Session.detach()
> -------------------------------------------------
>
> Key: WICKET-1010
> URL: https://issues.apache.org/jira/browse/WICKET-1010
> Project: Wicket
> Issue Type: Bug
> Reporter: Martin Funk
>
> What is the contract of Session.attach() and Session.detach() ?
> Especially, is it intended that after a call to attach() that there will
> be at least one call to detach() before the request goes back to the client?
> If that's the case, then there might be a bug in Session and I propose
> the following patch on org.apache.wicket.Session
> Index: .
> ===================================================================
> --- . (revision 579354)
> +++ . (working copy)
> @@ -305,6 +305,11 @@
> */
> public static void unset()
> {
> + Session session = (Session)current.get();
> + if (session != null)
> + {
> + session.detach();
> + }
> current.set(null);
> }
> In my current project well fell over this looking at:
> WicketFilter.getLastModified(final HttpServletRequest servletRequest)
> where cachable resources lead over Session.findOrCreate to
> Session.set(Session) to Session.attach()
> but the Session.unset() doesn't lead to a Session.detach()
> Martin
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
