On 1/19/07, Ryan <[EMAIL PROTECTED]> wrote:
> I think session#attach and #detach are some what undesirable for the
> purpose of clustering since attach and detach are called on every
> request rather than only on requests that bounce between servers.
Again, I'm not defending that method has to sta
I think session#attach and #detach are some what undesirable for the
purpose of clustering since attach and detach are called on every
request rather than only on requests that bounce between servers. I
would suggest removing it if it does not provide much value for
people... Gives less of a chance
I know, I'm not defending it, just explaining what I think was the
original idea behind it a long time ago.
Eelco
On 1/19/07, Igor Vaynberg <[EMAIL PROTECTED]> wrote:
> but that can be done lazily! we dont have imodel.attach()
>
> -igor
>
>
>
> On 1/19/07, Eelco Hillenius <[EMAIL PROTECTED] > wr
but that can be done lazily! we dont have imodel.attach()
-igor
On 1/19/07, Eelco Hillenius <[EMAIL PROTECTED]> wrote:
I vaguely remember WebSession#attach was meant for occasions where you
run in clustered mode and you want some way to resurrect session
variables. I think it has been in Wick
I vaguely remember WebSession#attach was meant for occasions where you
run in clustered mode and you want some way to resurrect session
variables. I think it has been in Wicket for a very long time.
But if no-one is using it we better remove it.
Eelco
On 1/19/07, Igor Vaynberg <[EMAIL PROTECTED
i dont even understand why we have session.attach(), we dont need it.
-igor
On 1/19/07, Johan Compagner <[EMAIL PROTECTED]> wrote:
And the locking on session should or can be removed i guess. Because it is
not really used anymore..
Because the lock for the component hierarchy is done on the p
And the locking on session should or can be removed i guess. Because it is
not really used anymore..
Because the lock for the component hierarchy is done on the pagemap level
when the page is get from the session.
But i can't completely see what happens if we really remove it
But if we move Sessi
this is sort of a gray area just because we havent come up with a formal
contract.
usually during processing of a request the session is used as the lock
object to sync threads, so during those times the session and page are
threadsafe (thats why you dont need to worry about syncs in your compone
I don't want to alarm anyone in that I have not seen this in the wild
however I came across a problem in my code recently that got me
thinking about race conditions and detachable models. I had a
detachable model that I was storing in my session object and decided
that Session.detach() and Session.
