Issue Details (XML | Word | Printable)

Key: JAVASERVERFACES_SPEC_PUBLIC-272
Type: Bug Bug
Status: Resolved Resolved
Resolution: Fixed
Priority: Major Major
Assignee: Ed Burns
Reporter: Ed Burns
Votes: 0
Watchers: 0
Operations

If you were logged in you would be able to see more operations.
javaserverfaces-spec-public

StateManagementRevision

Created: 02/Aug/07 09:39 AM   Updated: 25/Nov/10 06:43 PM   Resolved: 04/Mar/10 02:09 PM
Component/s: Uncategorized
Affects Version/s: 2.0
Fix Version/s: 1.2

Time Tracking:
Not Specified

Environment:

Operating System: All
Platform: All

Issue Links:
Dependency

Issuezilla Id: 272
Status Whiteboard:

EGTop5 effort_hard

Tags:
Participants: Ed Burns and pmuir


 Description  « Hide

Umbrella issue for state management revision in JSF 2.0.



Ed Burns added a comment - 02/Aug/07 09:43 AM

Add dependencies.


Ed Burns added a comment - 02/Aug/07 09:46 AM

>>>>> 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.


Ed Burns added a comment - 02/Aug/07 09:50 AM

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).


Ed Burns added a comment - 14/Aug/07 12:37 PM

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?


Ed Burns added a comment - 14/Aug/07 12:43 PM

dependency


Ed Burns added a comment - 07/Aug/08 08:28 AM

>>>>> 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?


pmuir added a comment - 02/Oct/08 05:08 AM

Add view expiry issue


Ed Burns added a comment - 15/Oct/08 06:52 AM

wb


Ed Burns added a comment - 11/Aug/09 12:48 PM

Fix checked in.


Ed Burns added a comment - 24/Nov/09 07:48 AM

Prepare to delete "spec" subcomponent.


Ed Burns added a comment - 04/Mar/10 02:09 PM

Move all to 1.2