On 11/14/05, Gary VanMatre <[EMAIL PROTECTED]> wrote: > > > [snip] > > > > > I take it this is to avoid keeping the list around when you don't need > it ( > > > i.e. you're not on the view containing the Ajax component)? I > presumeit must > > > be relatively cheap to populate the overall list in the first place? > > > > Yes that is the point. Its cheap enugh to create it for each dialog > > but not so cheap as for each keystroke. Unfortunately it has to be > > recreated b/c other users may be adding their own values to the list > > of possible values. > > > > The only other possibility I thought of was application scope and to > > invalidate that bean when a new value is added. Besides being a > > little complicated, I think you could run into threading issues. What > > if another request already has a reference to this bean as you are > > setting it to null? > > > > I've only glanced at this but I wonder if the commons transaction map > might work for a shared structure in application scope. > > http://jakarta.apache.org/commons/transaction/ > > On a tangent, I think it would be interesting to be able to scope "managed > bean state" with nested transactions. You could start a transaction on a > multi-page flow and have a check point on each page. Navigation to a > previous page could rollback the state of the managed beans to prior to the > check point. I guess it would require a deep clone. Might be to expensive > but seems like a cool feature.
Seam's take on this issue is to use a stateful session bean (but an EJB3 style one, to get all the ease of use improvements). Among other things, that lets you use all the transactional functionality that EJB provides, without having to do anything extra. Gary > Craig
