[JAVASERVERFACES_SPEC_PUBLIC-272] StateManagementRevision Created: 02/Aug/07  Updated: 01/Aug/14  Resolved: 04/Mar/10

Status: Closed
Project: javaserverfaces-spec-public
Component/s: Uncategorized
Affects Version/s: 2.0
Fix Version/s: 1.2

Type: Bug Priority: Major
Reporter: Ed Burns Assignee: Ed Burns
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Operating System: All
Platform: All

Issue Links:
depends on JAVASERVERFACES_SPEC_PUBLIC-153 Add property to UIData to enable tran... Closed
depends on JAVASERVERFACES_SPEC_PUBLIC-139 "Mostly Stateles" state saving Closed
depends on JAVASERVERFACES_SPEC_PUBLIC-143 Generics for Application Closed
depends on JAVASERVERFACES_SPEC_PUBLIC-226 Decoding section of SelectOne needs t... Closed
depends on JAVASERVERFACES_SPEC_PUBLIC-279 Tree Creation and State Saving Closed
depends on JAVASERVERFACES_SPEC_PUBLIC-290 UIViewScope - create a new scope, UIView Closed
depends on JAVASERVERFACES_SPEC_PUBLIC-252 StateHolder is difficult Closed
depends on JAVASERVERFACES_SPEC_PUBLIC-157 StateSaving: ViewState Object Closed
depends on JAVASERVERFACES_SPEC_PUBLIC-89 Client Script Support Closed
depends on JAVASERVERFACES_SPEC_PUBLIC-96 Annotation Use for StateSaving and Re... Closed
depends on JAVASERVERFACES_SPEC_PUBLIC-211 Expose the current processing compone... Closed
depends on JAVASERVERFACES_SPEC_PUBLIC-476 View expiry Closed
blocks JAVASERVERFACES_SPEC_PUBLIC-273 EZComp - Umbrella issue - Make develo... Closed
Issuezilla Id: 272
Status Whiteboard:

EGTop5 effort_hard


Umbrella issue for state management revision in JSF 2.0.

Comment by Ed Burns [ 02/Aug/07 ]

Add dependencies.

Comment by Ed Burns [ 02/Aug/07 ]

>>>>> On Fri, 27 Jul 2007 15:47:00 -0700, Igor Shabalov <ishabalov@EXADEL.COM> said:

IS> This is just another reason why we need to separate State from Component
IS> and threat it more granularly. With granular State we will have:
IS> 1. Nice separation between stateless (and there fore thread safe)
IS> portion of component, Request scope (tread local) and again thread safe
IS> state and - finally View Scope portion that must be synchronized.
IS> 2. Locks/synchronization can be used if only required, for example view
IS> can be locked only if some component need to save state till the end of
IS> request, so if some parallel request with partial update of other
IS> portion of same page does not have any statefull part - it will be not
IS> queued.

IS> Of course I'm not talking about Data Model concurrency - it's a separate
IS> story.

Comment by Ed Burns [ 02/Aug/07 ]

MM> Shouldn't we synchronize on whatever scope we invent that is the
MM> view-scope? Only one request may access the view (or its state,
MM> depending on how this is gonna change in implementation after we're
MM> through with 2.0) at a certain point of time, that's it.

AW> That's by far the simplest approach. This does cause major
AW> UI issues if you rely on it for AJAX requests, since one
AW> slow request (server/DB/network) blocks all subsequent requests.

IS> And now I think we should count separately Ajax vs regular requests.

AW> In terms of which? View scope, or state saving?
AW> If the former, I don't see why, if the latter,
AW> absolutely, in fact see:

AW> http://issues.apache.org/jira/browse/TRINIDAD-116
AW> PPR + State Management: reuse state tokens while PPRing to avoid flushing
the cache

AW> It's a big win for state longevity (or for memory use,
AW> if you use it to crank down the size of the state cache).

Comment by Ed Burns [ 14/Aug/07 ]

Some questions.

What is the granularity of state management?

attribute, component, sub-tree, other?

For saving, are we using push or pull?

For restoring, are we using push or pull?

Comment by Ed Burns [ 14/Aug/07 ]


Comment by Ed Burns [ 07/Aug/08 ]

>>>>> On Wed, 19 Mar 2008, David M Johnson said:

DJ> I think the goal should be to make JSF applications RESTful by
DJ> default, with proper use of GET and POST, i.e. only use POST when
DJ> application data is changing, not for component state. Another goal
DJ> should be clean, book-markable URLs that only carry path-info and
DJ> parameters needed by the application logic.

DJ> That's easy and the default situation with Rail, Grails, Struts, etc.
DJ> How hard would it be to redesign JSF along those lines? Would it
DJ> require EJB2 -> EJB3 level changes to JSF?

Comment by pmuir [ 02/Oct/08 ]

Add view expiry issue

Comment by Ed Burns [ 15/Oct/08 ]


Comment by Ed Burns [ 11/Aug/09 ]

Fix checked in.

Comment by Ed Burns [ 24/Nov/09 ]

Prepare to delete "spec" subcomponent.

Comment by Ed Burns [ 04/Mar/10 ]

Move all to 1.2

Comment by Manfred Riem [ 01/Aug/14 ]

Closing resolved issue out

Generated at Mon Mar 02 00:25:16 UTC 2015 using JIRA 6.2.3#6260-sha1:63ef1d6dac3f4f4d7db4c1effd405ba38ccdc558.