dev@javaserverfaces.java.net

RE: Re: [REVIEW/632] Server-side state saving sensitive to model changes

From: Jesse Alexander (KSFH 323) <"Jesse>
Date: Fri, 7 Sep 2007 11:32:22 +0200

+1 from me too on not making the serialization default. Serialization is
way too costly.

regards
Alexander

-----Original Message-----
From: Adam Winer [mailto:adam.winer_at_oracle.com]
Sent: Friday, September 07, 2007 12:28 AM
To: dev_at_javaserverfaces.dev.java.net
Subject: Re: [REVIEW/632] Server-side state saving sensitive to model
changes

I'd like to see some benchmarks first.

Based on my personal experience, I suspect this will
be a brutal hit to scalability, and would not recommend
serialization by default.

-- Adam


Michael Youngstrom wrote:
> My only problem with making serializing not default is that I'd hate
> for the RI to be smoked by some other JSF impls out there in random
> benchmarks because they're improperly handling server side state. :)
>
> However, for apps in my industry segment stability and consistency are
> more important than performance so I agree that server state should be
> serialized by default.
>
> Mike
>
> On 9/6/07, Ryan Lubke <Ryan.Lubke_at_sun.com> wrote:
>> Ryan Lubke wrote:
>>> Change bundle attached to the issue [1]
>>>
>>> The big question: Should serialization of server state be enabled
by
>>> default or not?
>> My two cents:
>>
>> From a technical standpoint, having parity with client-side state
>> saving is a good thing.
>> We don't want two different behaviors depending on which type a
client
>> application uses.
>>
>> That said, this is the first report I've seen on this issue, but that
>> doesn't mean people haven't
>> hit it and worked around it. So, I'm fine with changing the default
to
>> false and documenting
>> it's usage so if someone hits this in the future, then can flip this
switch.
>>
>>
>>>
>>> [1] https://javaserverfaces.dev.java.net/issues/show_bug.cgi?id=632
>>>
>>>
---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe_at_javaserverfaces.dev.java.net
>>> For additional commands, e-mail:
dev-help_at_javaserverfaces.dev.java.net
>>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe_at_javaserverfaces.dev.java.net
>> For additional commands, e-mail:
dev-help_at_javaserverfaces.dev.java.net
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_javaserverfaces.dev.java.net
> For additional commands, e-mail: dev-help_at_javaserverfaces.dev.java.net
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe_at_javaserverfaces.dev.java.net
For additional commands, e-mail: dev-help_at_javaserverfaces.dev.java.net