Gary, I agree that EJB can be overkill in some instances. I wanted to use transactions in my COR solution so I did some cool stuff with commons-chain. I used the "Filter" object (extends Command) which guarantees that its postprocess method will be called if its execute method is called. I created a Filter class that I called Transaction.
In the execute method I create a Stack object and put it in the chain context. I also push an instance of 'this' onto that stack. This is so if you have multiple chains with a Transaction in the chain, you can make sure they are all finished before you commit the transaction. You would of course pop these references in the postprocess command. In the final postprocess command (you know its final because the stack is now empty), you can commit the transactions. I combined this with ThreadLocal so that I could have database transactions with connection pooling without the rest of the hassle of EJB. Maybe you could do something like this. sean On 11/15/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. > > True, I didn't consider that. I guess that I was thinking in terms of being > able to create a transactional unit-of-work on a non distributed object, a > simple POJO. I guess that EJB3 will do that but not in a simple web module. > > >>Gary > > > > > >Craig > > Gary > > > > > > > ---------- Forwarded message ---------- > From: Craig McClanahan <[EMAIL PROTECTED]> > To: Struts Developers List <[email protected]> > Date: Tue, 15 Nov 2005 05:48:25 +0000 > Subject: Re: [shale] Using RemoteCommand with Dialogs > 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 > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
