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