another one: All that stuff has nothing to do with the RenderKit and should go into org.apache.myfaces.application.viewstate. wdyt?
Also the following classes are related and should imo get moved to this new package: * StateCache * StateCacheFactory * StateManagerImpl LieGrue, strub ----- Original Message ----- > From: Mark Struberg <[email protected]> > To: MyFaces Development <[email protected]> > Cc: > Sent: Thursday, November 15, 2012 5:02 PM > Subject: Re: StateSaving review > > 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. >>> >> >
