> -----Original Message-----
> From: Joe Hertz [mailto:[EMAIL PROTECTED]
> Sent: Tuesday, August 24, 2004 10:11 AM
> To: 'Struts Users Mailing List'
> Subject: RE: I suspect this is a bad idea...so what's a better one?
>
>
> > 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.
Okay so what's wrong with a base action whose execute method then calls your execute
method, but everything is setup. Pass in the objects you've set up in a hash table
for easy lookup.....
Something like
blah execute( blah) {
//setup things
//put them in hash table
executeLogic( map, request, response, blah, setupStuff);
//close things whatever.
}
>
> 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.
>
> 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...
Except that you have just create a request scope variable ( one thread, one
request)the painful way.... When what you really want, it sounds like, is an
application scope variable that you can get at.
However, I think what you'll find is that you end up with a bottleneck on the
persistance object, because you have multiple threads hitting it, which means that
most of them will be waiting on the lock to be lifted. This is why this particular
problem has never been solved, it creates a really nasty performance bottleneck.
Believe it or not it's actually cheaper to create and destroy the persistance objects
on the fly then it is to make it thread safe.... because you will always have a lot of
threads hitting the site.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
