I now refactored the classes into an own viewstate package, moved out the inner classes and added a bit JavaDocs.
I think this gives a much better overview about the complexity of this area. This is always the first step towards improving something. LieGrue, strub ----- Original Message ----- > From: Mark Struberg <[email protected]> > To: MyFaces Development <[email protected]> > Cc: > Sent: Thursday, November 15, 2012 4:56 PM > Subject: Re: StateSaving review > > You are completely right. > > * If the session gets passivated and restored on server restart, we will > still > get the next number -> no collision > * if the session gets moved to another node it usually gets rewritten -> no > collision > * if the session doesn't get passivated on server reboot we will get another > session -> no collision > > > The only scenario I know is if the load balancer is not correctly configured. > Or > some requests are sticking in the queue and then dispatched to different > nodes. > But I consider this a badly configured cluster - though I have seen this > quite > some time already :( > > Those kind of clusters have problems with requests rushing in from the client > in > a very short time and getting dispatched to different nodes. If the time is > shorter than the time needed to sync the sessions to the other nodes, then > your > state is f****d up. But that's not really a problem of MyFaces to be honest > > > Thus if we switch to a AtomicInteger we would be perfectly fine even without > any > additional info. > > LieGrue, > strub > > > > ----- Original Message ----- >> From: Mike Kienenberger <[email protected]> >> To: MyFaces Development <[email protected]>; Mark Struberg > <[email protected]> >> Cc: >> Sent: Thursday, November 15, 2012 4:34 PM >> Subject: Re: StateSaving review >> >> On Thu, Nov 15, 2012 at 10:28 AM, Mark Struberg <[email protected]> > wrote: >>> b.) candidate 1: CounterKeyFactory. If we like to prevent reboot > clashes >> then we might add another int which contains a random value. Think about > having >> a Server with a single page right now. Click on it a few times, then > restart >> myfaces and issue a few requests to the same page and go back in your > browser >> history. Proposal: instead of the viewId we should add a random number. >> >> I was wondering about this as well at first. But isn't this counter >> per session? So when the server restarts, a new session would be >> created and there wouldn't be a problem. I guess I should have asked >> to make sure. >> >
