Daniel Pfeifer wrote:
That might be slightly off-topic, but it fits to the subject. However, personally I think that webwork is quite slow once you do some serious work with it. We are testing a webwork-based website on a P4 3Ghz plus 1 gig of RAM and some requests really do take ages (especially when the ValueStack is involved) to complete. I hope you find some ways to improve it before WW2 goes final.
/Daniel
-----Original Message----- From: Patrick Lightbody [mailto:[EMAIL PROTECTED] Sent: den 8 januari 2004 17:10 To: [EMAIL PROTECTED] Subject: RE: [OS-webwork] Xwork/WebWork2 under extreme load
Well, about a year ago when we had the initial XW meetings, it was decided to keep the TL for now. Maybe post-2.0 we'll find ways to slowly migrate away from it. I agree though, ThreadLocals suck ass.
-----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Scott Farquhar Sent: Wednesday, January 07, 2004 6:00 PM To: [EMAIL PROTECTED] Subject: Re: [OS-webwork] Xwork/WebWork2 under extreme load
On Wed, Jan 07, 2004 at 11:56:28PM +0100, Jens Riboe wrote: > What was the design rationale for putting it in thread local storage? > > This works for servlets, but it may cause mysterious bugs in Swing > applications, every time one uses a worker thread for a time consuming > UI event. > > How about putting state info, like actionCtx, config, etc into > a single XWork object and then let the impl choose to store it > appropriately. The ctx can then be created from that object. > > For a servlet one can use thread-based singleton, like above > or put it into the servletCtx, and the actionCtx can be created and stored > into the request. > > For a Swing app, it generally suffice to go for a classloader singleton, > aka static variable, for both config and actionCtx.
I like the way that PicoContainer has done it:
public interface ObjectReference { Object get();
void set(Object item); }
Then there can be a ThreadLocalObjectReference, or a SingletonObjectReference as needed.
I've needed to change the way that things are stored in Pico, and it was a 5 line change due to this abstraction.
So you have the ActionContext take an ObjectReference of where to store itself?
Cheers, Scott
------------------------------------------------------- This SF.net email is sponsored by: Perforce Software. Perforce is the Fast Software Configuration Management System offering advanced branching capabilities and atomic changes on 50+ platforms. Free Eval! http://www.perforce.com/perforce/loadprog.html _______________________________________________ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
------------------------------------------------------- This SF.net email is sponsored by: Perforce Software. Perforce is the Fast Software Configuration Management System offering advanced branching capabilities and atomic changes on 50+ platforms. Free Eval! http://www.perforce.com/perforce/loadprog.html _______________________________________________ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
------------------------------------------------------- This SF.net email is sponsored by: Perforce Software. Perforce is the Fast Software Configuration Management System offering advanced branching capabilities and atomic changes on 50+ platforms. Free Eval! http://www.perforce.com/perforce/loadprog.html _______________________________________________ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
