Re: Struts Actions are Singletons?
Pertainig to the paragraf below extracted from the Craig response, I wonder a question. What happens in clustered environments, where the VM can be swap in a per request basis? State is not lost if it is maintained in session since, as far as I know, server is able to serialize the session and feed next server with session state, BUT by using stack objects, state could be lost, is not it? I would appreciate opinions, Craig opinion especially welcome, since in my understanding implementation of stacks per thread in such a case is quite tricky since servers can be balanced. Regards, Adolfo. * Java's implementation of a stack per thread (which is where the local variables go) makes it easy to avoid most threading problems by simply using local variables for the per-request information. From: Craig R. McClanahan [EMAIL PROTECTED] Reply-To: Struts Users Mailing List [EMAIL PROTECTED] To: Struts Users Mailing List [EMAIL PROTECTED] Subject: Re: Struts Actions are Singletons? Date: Wed, 24 Apr 2002 11:25:20 -0700 (PDT) On Wed, 24 Apr 2002 [EMAIL PROTECTED] wrote: Date: Wed, 24 Apr 2002 13:43:26 -0400 From: [EMAIL PROTECTED] Reply-To: Struts Users Mailing List [EMAIL PROTECTED] To: Struts Users Mailing List [EMAIL PROTECTED] Subject: Re: Struts Actions are Singletons? Can someone explain why these are created as singletons in the first place? Are you speaking of Action instances? If so, they are created as singletons for a number of reasons: * The threading behavior of Actions are exactly the same as those of servlets and JSP pages, where it is quite common for several requests to be present in your Action at the same time. * Java's implementation of a stack per thread (which is where the local variables go) makes it easy to avoid most threading problems by simply using local variables for the per-request information. * At the same time, it is quite common to have some of your data shared across all requests that use a particular Action. An example would be a list of valid values for a particular form bean property -- you might well choose to read that information into a shared variable at the beginning of your application, instead of going to the database on every request. An instance variable inside the action (or perhaps a servlet context attribute if you need the list as part of your UI also) makes a perfectly reasonable place to store these. Moving instance variables into the session, by the way, reduces (but does not eliminate) multiple thread concerns. You still need to be aware of multiple requests accessing the same session at the same time. How is that possible?, you might ask -- consider: * User submits a form to a long running transaction, gets impatient, presses STOP, and goes somewhere else in your app (and therefore in the same session) before the first request has completed. * You are using frames -- most browsers will submit multiple simultaneous requests that will typically be accessing the same session. Craig -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] HTML HEAD TITLEAdolfo's signature/TITLE /HEAD BODY centerbemAdolfo Rodriguez Miguelez/emb/center /BODY /HTML _ Join the worlds largest e-mail service with MSN Hotmail. http://www.hotmail.com -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: Struts Actions are Singletons?
The local variables mentioned below, are method scope. They have no baring on sessions. For session held objects, yes, a cluster would need to replicate them (hence they need to be Serializable). However, the servlet spec mandates that all requests for a session, should go to the same VM. Only in fail-over would the VM change. -Original Message- From: Adolfo Miguelez [mailto:[EMAIL PROTECTED]] Sent: 25 April 2002 14:36 To: [EMAIL PROTECTED] Subject: Re: Struts Actions are Singletons? Pertainig to the paragraf below extracted from the Craig response, I wonder a question. What happens in clustered environments, where the VM can be swap in a per request basis? State is not lost if it is maintained in session since, as far as I know, server is able to serialize the session and feed next server with session state, BUT by using stack objects, state could be lost, is not it? I would appreciate opinions, Craig opinion especially welcome, since in my understanding implementation of stacks per thread in such a case is quite tricky since servers can be balanced. Regards, Adolfo. * Java's implementation of a stack per thread (which is where the local variables go) makes it easy to avoid most threading problems by simply using local variables for the per-request information. From: Craig R. McClanahan [EMAIL PROTECTED] Reply-To: Struts Users Mailing List [EMAIL PROTECTED] To: Struts Users Mailing List [EMAIL PROTECTED] Subject: Re: Struts Actions are Singletons? Date: Wed, 24 Apr 2002 11:25:20 -0700 (PDT) On Wed, 24 Apr 2002 [EMAIL PROTECTED] wrote: Date: Wed, 24 Apr 2002 13:43:26 -0400 From: [EMAIL PROTECTED] Reply-To: Struts Users Mailing List [EMAIL PROTECTED] To: Struts Users Mailing List [EMAIL PROTECTED] Subject: Re: Struts Actions are Singletons? Can someone explain why these are created as singletons in the first place? Are you speaking of Action instances? If so, they are created as singletons for a number of reasons: * The threading behavior of Actions are exactly the same as those of servlets and JSP pages, where it is quite common for several requests to be present in your Action at the same time. * Java's implementation of a stack per thread (which is where the local variables go) makes it easy to avoid most threading problems by simply using local variables for the per-request information. * At the same time, it is quite common to have some of your data shared across all requests that use a particular Action. An example would be a list of valid values for a particular form bean property -- you might well choose to read that information into a shared variable at the beginning of your application, instead of going to the database on every request. An instance variable inside the action (or perhaps a servlet context attribute if you need the list as part of your UI also) makes a perfectly reasonable place to store these. Moving instance variables into the session, by the way, reduces (but does not eliminate) multiple thread concerns. You still need to be aware of multiple requests accessing the same session at the same time. How is that possible?, you might ask -- consider: * User submits a form to a long running transaction, gets impatient, presses STOP, and goes somewhere else in your app (and therefore in the same session) before the first request has completed. * You are using frames -- most browsers will submit multiple simultaneous requests that will typically be accessing the same session. Craig -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] HTML HEAD TITLEAdolfo's signature/TITLE /HEAD BODY centerbemAdolfo Rodriguez Miguelez/emb/center /BODY /HTML _ Join the world's largest e-mail service with MSN Hotmail. http://www.hotmail.com -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] Visit our website at http://www.ubswarburg.com This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. E-mail transmission cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. The sender therefore does not accept liability for any errors or omissions in the contents of this message which arise as a result of e-mail transmission. If verification is required please request a hard-copy version
Re: Struts Actions are Singletons?
Regarding Action Instances: They are stored in HashMap (FastHashMap actually) that is kept by the primary ActionServlet. This ActionServlet is the same one as is defined as a startup servlet in the web.xml of each web application running struts in a particular servlet container instance. While some of this may depend on your particular servlet container, I'd venture to guess that its likely that information isn't replicated between clustered container instances unless the information is specifically put on the Session (or potentially, the Application) context. That's not the case with the Action instances - they are stored in the memory space used by the servlet itself. So it looks like this information is likely not replicated among clustered instances. But really what does it matter? It's unlikely that you'll be storing session information in an Action instance that is shared by multiple sessions anyway. In other words, since you're not going to store per-session information in the Action instance, replication of session information in a cluster is irrelevant. That being said, it may be possible that APPLICATION-LEVEL configuration information may get out of whack if it is stored in an Action instance. Each container would maintain this information independantly, so this may be something to look out for. FWIW - Kevin Adolfo Miguelez [EMAIL PROTECTED] on 04/25/2002 09:36:23 AM Please respond to Struts Users Mailing List [EMAIL PROTECTED] To: [EMAIL PROTECTED] cc: Subject: Re: Struts Actions are Singletons? Pertainig to the paragraf below extracted from the Craig response, I wonder a question. What happens in clustered environments, where the VM can be swap in a per request basis? State is not lost if it is maintained in session since, as far as I know, server is able to serialize the session and feed next server with session state, BUT by using stack objects, state could be lost, is not it? I would appreciate opinions, Craig opinion especially welcome, since in my understanding implementation of stacks per thread in such a case is quite tricky since servers can be balanced. Regards, Adolfo. * Java's implementation of a stack per thread (which is where the local variables go) makes it easy to avoid most threading problems by simply using local variables for the per-request information. From: Craig R. McClanahan [EMAIL PROTECTED] Reply-To: Struts Users Mailing List [EMAIL PROTECTED] To: Struts Users Mailing List [EMAIL PROTECTED] Subject: Re: Struts Actions are Singletons? Date: Wed, 24 Apr 2002 11:25:20 -0700 (PDT) On Wed, 24 Apr 2002 [EMAIL PROTECTED] wrote: Date: Wed, 24 Apr 2002 13:43:26 -0400 From: [EMAIL PROTECTED] Reply-To: Struts Users Mailing List [EMAIL PROTECTED] To: Struts Users Mailing List [EMAIL PROTECTED] Subject: Re: Struts Actions are Singletons? Can someone explain why these are created as singletons in the first place? Are you speaking of Action instances? If so, they are created as singletons for a number of reasons: * The threading behavior of Actions are exactly the same as those of servlets and JSP pages, where it is quite common for several requests to be present in your Action at the same time. * Java's implementation of a stack per thread (which is where the local variables go) makes it easy to avoid most threading problems by simply using local variables for the per-request information. * At the same time, it is quite common to have some of your data shared across all requests that use a particular Action. An example would be a list of valid values for a particular form bean property -- you might well choose to read that information into a shared variable at the beginning of your application, instead of going to the database on every request. An instance variable inside the action (or perhaps a servlet context attribute if you need the list as part of your UI also) makes a perfectly reasonable place to store these. Moving instance variables into the session, by the way, reduces (but does not eliminate) multiple thread concerns. You still need to be aware of multiple requests accessing the same session at the same time. How is that possible?, you might ask -- consider: * User submits a form to a long running transaction, gets impatient, presses STOP, and goes somewhere else in your app (and therefore in the same session) before the first request has completed. * You are using frames -- most browsers will submit multiple simultaneous requests that will typically be accessing the same session. Craig -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] HTML HEAD TITLEAdolfo's signature/TITLE /HEAD BODY centerbemAdolfo Rodriguez Miguelez/emb/center /BODY
Re: Struts Actions are Singletons?
On Thu, 25 Apr 2002, Adolfo Miguelez wrote: Date: Thu, 25 Apr 2002 13:36:23 + From: Adolfo Miguelez [EMAIL PROTECTED] Reply-To: Struts Users Mailing List [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Re: Struts Actions are Singletons? Pertainig to the paragraf below extracted from the Craig response, I wonder a question. What happens in clustered environments, where the VM can be swap in a per request basis? In the servlet specification, support for this is described as a distributed container, and you include the distributable/ attribute in your web.xml file to indicate that you've programmed to a couple of extra standards to work correctly in such an environment. State is not lost if it is maintained in session since, as far as I know, server is able to serialize the session and feed next server with session state, BUT by using stack objects, state could be lost, is not it? State can be maintained in the session, even in the face of load balancing and failover, as long as you make all of your sesson attribute classes implement Serializable (and that restriction applies to any instance variables inside your session attributes as well). Note that the container has a useful restriction -- all requests for a particular session, at a particular time, must be answered by one instance. In other words, migration can only happen in between requests. From the application perspective, that lets you deal with thread safety issues here exactly like you do in a single-server environment. For example, you don't ever have to figure out how to synchornize a session attribute across multiple JVMs. For stuff on the stack, remember that it only has a maximum lifetime equal to the length of an individual request itself (just like request attributes), even in the non-load-balanced case. That is why, for example, you must include input fields for *all* your form bean properties when you are using request scope form beans, so that the entire state can be restored. Therefore, you've got no problems unless the server tries to migrate your request in the middle of that request. And I don't know of any servers that actually try that. I would appreciate opinions, Craig opinion especially welcome, since in my understanding implementation of stacks per thread in such a case is quite tricky since servers can be balanced. If you want to rely on more than my opinion :-), you would find some very useful information in the Servlet Specification (version 2.3) and the J2EE Platform Specification (version 1.3). These describe the programming environments that portable applications can expect in a J2EE container - even one that supports advanced features like load balancing and failover. Containers can provide additional capabilities, and it's certainly possible to write applications dependent on those capabilities - but it's our responsibility as developers to understand what is portable and what is not. Regards, Adolfo. Craig -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Struts Actions are Singletons?
On Thu, 25 Apr 2002 [EMAIL PROTECTED] wrote: Date: Thu, 25 Apr 2002 09:59:29 -0400 From: [EMAIL PROTECTED] Reply-To: Struts Users Mailing List [EMAIL PROTECTED] To: Struts Users Mailing List [EMAIL PROTECTED] Subject: Re: Struts Actions are Singletons? Regarding Action Instances: They are stored in HashMap (FastHashMap actually) that is kept by the primary ActionServlet. This ActionServlet is the same one as is defined as a startup servlet in the web.xml of each web application running struts in a particular servlet container instance. Which means that, in a distributed container running a Struts based app, there really is more than one copy of the controller servlet (one per server instance). Presumably, you have deployed exactly the same WAR file on every server, so that the Struts configurations are identical, which means therefore that the application scope attributes that Struts sets up are identical. While some of this may depend on your particular servlet container, I'd venture to guess that its likely that information isn't replicated between clustered container instances unless the information is specifically put on the Session (or potentially, the Application) context. That's not the case with the Action instances - they are stored in the memory space used by the servlet itself. So it looks like this information is likely not replicated among clustered instances. There are some containers that try to make some promises about synchronizing application scope stuff, but it is outside the boundaries of the J2EE specifications. If you want to share information across instances portably, it should be written to some external store (database, EJBs, whatever) that is accessed from all of the instances. But really what does it matter? It's unlikely that you'll be storing session information in an Action instance that is shared by multiple sessions anyway. In other words, since you're not going to store per-session information in the Action instance, replication of session information in a cluster is irrelevant. That being said, it may be possible that APPLICATION-LEVEL configuration information may get out of whack if it is stored in an Action instance. Each container would maintain this information independantly, so this may be something to look out for. I normally use instance variables in an Action (or application-scope attributes in the servlet context) only to cache read-only copies of stuff that needs to be accessed repeatedly. Anything that changes over time needs to be written back out to the database -- not only to share it, but to ensure that it is not lost in case the servlet container crashes. FWIW - Kevin Craig -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: Struts Actions are Singletons?
-Original Message- From: abhishek srivastava [mailto:[EMAIL PROTECTED]] Are the Action classes that we write for Struts Singletons? or are they created and destroyed per request. http://jakarta.apache.org/struts/doc-1.0.2/userGuide/building_controller.htm l#action_classes Excerpt: The controller servlet creates only one instance of your Action class, and uses it for all requests. Thus, you need to code your Action class so that it operates correctly in a multi-threaded environment, just as you must code a servlet's service() method safely. Cheers, Laird -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Struts Actions are Singletons?
And to make it thread safe I have use synchronize blocks of code which can cause all the requests to get queued up. (Java has lock per object, therefore if my code had 2 synchronized blocks, then the 2nd block would lock up even when the first one is being executed.) Isn't this bad for performance? regards, Abhishek. - Original Message - From: Nelson, Laird [EMAIL PROTECTED] To: 'Struts Users Mailing List' [EMAIL PROTECTED] Sent: Wednesday, April 24, 2002 6:27 PM Subject: RE: Struts Actions are Singletons? -Original Message- From: abhishek srivastava [mailto:[EMAIL PROTECTED]] Are the Action classes that we write for Struts Singletons? or are they created and destroyed per request. http://jakarta.apache.org/struts/doc-1.0.2/userGuide/building_controller.htm l#action_classes Excerpt: The controller servlet creates only one instance of your Action class, and uses it for all requests. Thus, you need to code your Action class so that it operates correctly in a multi-threaded environment, just as you must code a servlet's service() method safely. Cheers, Laird -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Struts Actions are Singletons?
Action classes are only a gateway to your business logic. You would just have to create and use business objects for your request. If you need synchronized blocks, it's looks like your Action has some instance properties that cannot be shared with other requests. I think this properties would have to be a business class or an value object class that could be created by Action and passed to Action methods or business methods, so beeing threadsafe. If you realy need to synchronize access to some ressources, try to put this into a dedicated class that will manage this ressources, so that the synchronized mecanism will be in this manager class. And to make it thread safe I have use synchronize blocks of code which can cause all the requests to get queued up. (Java has lock per object, therefore if my code had 2 synchronized blocks, then the 2nd block would lock up even when the first one is being executed.) Isn't this bad for performance? regards, Abhishek. - Original Message - From: Nelson, Laird [EMAIL PROTECTED] To: 'Struts Users Mailing List' [EMAIL PROTECTED] Sent: Wednesday, April 24, 2002 6:27 PM Subject: RE: Struts Actions are Singletons? -Original Message- From: abhishek srivastava [mailto:[EMAIL PROTECTED]] Are the Action classes that we write for Struts Singletons? or are they created and destroyed per request. http://jakarta.apache.org/struts/doc-1.0.2/userGuide/building_controller.htm l#action_classes Excerpt: The controller servlet creates only one instance of your Action class, and uses it for all requests. Thus, you need to code your Action class so that it operates correctly in a multi-threaded environment, just as you must code a servlet's service() method safely. Cheers, Laird -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: Struts Actions are Singletons?
-Original Message- From: Abhishek Srivastava [mailto:[EMAIL PROTECTED]] And to make it thread safe I have use synchronize blocks of code which can cause all the requests to get queued up. (Java has lock per object, therefore if my code had 2 synchronized blocks, then the 2nd block would lock up even when the first one is being executed.) Isn't this bad for performance? Right; you should ensure that your Action class does not define or use instance variables of its own, since they will, by definition, not be request-specific. If you find you *must* define them, then yes, you should synchronize access to them, as they could be accessed by many threads simulataneously. Hope this helps. Cheers, Laird -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Struts Actions are Singletons?
The suggestion I've seen on this is to move all instance variables to the session. Of course, that doesn't guarantee thread-safety either - but it comes a whole lot closer. - Original Message - From: Nelson, Laird [EMAIL PROTECTED] To: 'Struts Users Mailing List' [EMAIL PROTECTED] Sent: Wednesday, April 24, 2002 8:59 AM Subject: RE: Struts Actions are Singletons? -Original Message- From: Abhishek Srivastava [mailto:[EMAIL PROTECTED]] And to make it thread safe I have use synchronize blocks of code which can cause all the requests to get queued up. (Java has lock per object, therefore if my code had 2 synchronized blocks, then the 2nd block would lock up even when the first one is being executed.) Isn't this bad for performance? Right; you should ensure that your Action class does not define or use instance variables of its own, since they will, by definition, not be request-specific. If you find you *must* define them, then yes, you should synchronize access to them, as they could be accessed by many threads simulataneously. Hope this helps. Cheers, Laird -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Struts Actions are Singletons?
Can someone explain why these are created as singletons in the first place? Eddie Bush [EMAIL PROTECTED] on 04/24/2002 01:49:35 PM Please respond to Struts Users Mailing List [EMAIL PROTECTED] To: Struts Users Mailing List [EMAIL PROTECTED] cc: Subject: Re: Struts Actions are Singletons? The suggestion I've seen on this is to move all instance variables to the session. Of course, that doesn't guarantee thread-safety either - but it comes a whole lot closer. - Original Message - From: Nelson, Laird [EMAIL PROTECTED] To: 'Struts Users Mailing List' [EMAIL PROTECTED] Sent: Wednesday, April 24, 2002 8:59 AM Subject: RE: Struts Actions are Singletons? -Original Message- From: Abhishek Srivastava [mailto:[EMAIL PROTECTED]] And to make it thread safe I have use synchronize blocks of code which can cause all the requests to get queued up. (Java has lock per object, therefore if my code had 2 synchronized blocks, then the 2nd block would lock up even when the first one is being executed.) Isn't this bad for performance? Right; you should ensure that your Action class does not define or use instance variables of its own, since they will, by definition, not be request-specific. If you find you *must* define them, then yes, you should synchronize access to them, as they could be accessed by many threads simulataneously. Hope this helps. Cheers, Laird -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] --- This e-mail message (including attachments, if any) is intended for the use of the individual or entity to which it is addressed and may contain information that is privileged, proprietary , confidential and exempt from disclosure. If you are not the intended recipient, you are notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please notify the sender and erase this e-mail message immediately. --- -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: Struts Actions are Singletons?
To conserve server resources and for thread safety. Mark -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Sent: Wednesday, April 24, 2002 1:43 PM Can someone explain why these are created as singletons in the first place? -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Struts Actions are Singletons?
On Wed, 24 Apr 2002 [EMAIL PROTECTED] wrote: Date: Wed, 24 Apr 2002 13:43:26 -0400 From: [EMAIL PROTECTED] Reply-To: Struts Users Mailing List [EMAIL PROTECTED] To: Struts Users Mailing List [EMAIL PROTECTED] Subject: Re: Struts Actions are Singletons? Can someone explain why these are created as singletons in the first place? Are you speaking of Action instances? If so, they are created as singletons for a number of reasons: * The threading behavior of Actions are exactly the same as those of servlets and JSP pages, where it is quite common for several requests to be present in your Action at the same time. * Java's implementation of a stack per thread (which is where the local variables go) makes it easy to avoid most threading problems by simply using local variables for the per-request information. * At the same time, it is quite common to have some of your data shared across all requests that use a particular Action. An example would be a list of valid values for a particular form bean property -- you might well choose to read that information into a shared variable at the beginning of your application, instead of going to the database on every request. An instance variable inside the action (or perhaps a servlet context attribute if you need the list as part of your UI also) makes a perfectly reasonable place to store these. Moving instance variables into the session, by the way, reduces (but does not eliminate) multiple thread concerns. You still need to be aware of multiple requests accessing the same session at the same time. How is that possible?, you might ask -- consider: * User submits a form to a long running transaction, gets impatient, presses STOP, and goes somewhere else in your app (and therefore in the same session) before the first request has completed. * You are using frames -- most browsers will submit multiple simultaneous requests that will typically be accessing the same session. Craig -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: Struts Actions are Singletons?
Thanks for that excellent explanation, that has certainly cleared some things up. Now I understand why the Actions are singletons, and I believe I understand from the STRUTS code _how_ the singletons are enforced, but I'd like to ask another 2 questions to make sure: 1. I notice that the only location that the singleton rules are enforced is when a request is made for the Action object itself, in which case it is retreived from the Hash map. So the Action class itself doesn't implement any of the singleton design pattern since it's already enforced in the servlet? 2. In reference to Action Forms, the singleton rules are enforced when a request for an Action form is checked against what is in the request or session, depending on the form scope. So in this case, the singletons are enforced on a per user basis? -Original Message- From: Craig R. McClanahan [mailto:[EMAIL PROTECTED]] Sent: Wednesday, April 24, 2002 2:25 PM To: Struts Users Mailing List Subject: Re: Struts Actions are Singletons? On Wed, 24 Apr 2002 [EMAIL PROTECTED] wrote: Date: Wed, 24 Apr 2002 13:43:26 -0400 From: [EMAIL PROTECTED] Reply-To: Struts Users Mailing List [EMAIL PROTECTED] To: Struts Users Mailing List [EMAIL PROTECTED] Subject: Re: Struts Actions are Singletons? Can someone explain why these are created as singletons in the first place? Are you speaking of Action instances? If so, they are created as singletons for a number of reasons: * The threading behavior of Actions are exactly the same as those of servlets and JSP pages, where it is quite common for several requests to be present in your Action at the same time. * Java's implementation of a stack per thread (which is where the local variables go) makes it easy to avoid most threading problems by simply using local variables for the per-request information. * At the same time, it is quite common to have some of your data shared across all requests that use a particular Action. An example would be a list of valid values for a particular form bean property -- you might well choose to read that information into a shared variable at the beginning of your application, instead of going to the database on every request. An instance variable inside the action (or perhaps a servlet context attribute if you need the list as part of your UI also) makes a perfectly reasonable place to store these. Moving instance variables into the session, by the way, reduces (but does not eliminate) multiple thread concerns. You still need to be aware of multiple requests accessing the same session at the same time. How is that possible?, you might ask -- consider: * User submits a form to a long running transaction, gets impatient, presses STOP, and goes somewhere else in your app (and therefore in the same session) before the first request has completed. * You are using frames -- most browsers will submit multiple simultaneous requests that will typically be accessing the same session. Craig -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: Struts Actions are Singletons?
On Wed, 24 Apr 2002, Schmidt, Carl wrote: Date: Wed, 24 Apr 2002 15:16:43 -0400 From: Schmidt, Carl [EMAIL PROTECTED] Reply-To: Struts Users Mailing List [EMAIL PROTECTED] To: 'Struts Users Mailing List' [EMAIL PROTECTED] Subject: RE: Struts Actions are Singletons? Thanks for that excellent explanation, that has certainly cleared some things up. Now I understand why the Actions are singletons, and I believe I understand from the STRUTS code _how_ the singletons are enforced, but I'd like to ask another 2 questions to make sure: 1. I notice that the only location that the singleton rules are enforced is when a request is made for the Action object itself, in which case it is retreived from the Hash map. So the Action class itself doesn't implement any of the singleton design pattern since it's already enforced in the servlet? I'm not positive what you mean by implements any of the singleton design pattern, but it is true that Struts relies on the fact that Actions are either created or looked up in one and only one place in the controller servlet. Because the controller servlet itself is a singleton (don't you just love recursive justifications? :-), this turns out to be the only way that the framework itself ever creates actions; hence, the singleton nature of the Actions is preserved. 2. In reference to Action Forms, the singleton rules are enforced when a request for an Action form is checked against what is in the request or session, depending on the form scope. So in this case, the singletons are enforced on a per user basis? Action forms are *not* singletons -- there is a form instance per concurrent request (assuming that your action is defined to require one). Whether the form persists after the end of the request depends on which scope you put it in. From a programming point of view, you can think of form beans in request scope just like you think of local variables -- there is a copy per thread, so you don't have to worry about synchronizing anything inside them (although you would if the form bean was saved in session scope). Craig -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: Struts Actions are Singletons?
On both the accessors and mutators? Mark -Original Message- From: Craig R. McClanahan [mailto:[EMAIL PROTECTED]] Sent: Wednesday, April 24, 2002 3:56 PM From a programming point of view, you can think of form beans in request scope just like you think of local variables -- there is a copy per thread, so you don't have to worry about synchronizing anything inside them (although you would if the form bean was saved in session scope). Craig -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
