On Tue, 24 Aug 2004 13:10:50 -0400, Joe Hertz <[EMAIL PROTECTED]> wrote: > > It seems like you're over engineering something that is > > simple... what problem are you trying to solve with this? > > I want to be able to do alot of the mundane setup stuff that happens in > every action method without having to think aboout it. > > Rather than having every method create and destroy a Persistence object, I'd > have an execute() method that created it, called super.execute() and > destroyed it. >
Sounds like you really want a Filter that creates the persistence object on the way in (storing it in a request attribute, so that it's accessible in the Action.execute() method), and cleaning up on the way out. > The problem is getting this thing into the scope of the "real" Action > method. A class level protected variable to store the persistence object > seemed the best option, but it's not safe as it gets shared by every call > into the class. > > I could make the Persistence Object itself a ThreadLocal, but then I've > changed the creation step for a conversion step inside of the Action method. > Delegates have a footprint alteration to the current Action methods. *That* > seemed to me like over-engineering for this problem. > > But If the Persistence class itself *is* threadsafe, then I shouldnt have an > issue, I figure if the Actions share them. Nothing but static public methods > and static ThreadLocal class variables. I really only need one or two class > level variables, and making them ThreadLocal isn't as gross of a change for > me. I'm just hoping a hole gets popped into the theory before rather than > after implementation... > I would investigate very very carefully before I ever believed that a persistence object could really be shared safely. I would think long and hard about how you would ever shut down the thread local persistence objects when the application shuts down. I would wonder about why you'd be willing to have ThreadLocal variables hanging around just because I happened to use that thread once for a request, and might never do so again (either because it killed the thread or because the number of concurrent requests when back down from a peak). > -Joe Craig --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
