"Threadsafe" WebObjects Applications
I recently asked the WO community list about this
and Chuck Hill's reply was excellent and definitely of use to me and anyone else
wondering "how do I make my WO app thread-safe?"...
On Feb 14, 2005, at 6:44 PM, Chuck Hill
wrote:
Well, OK, I'll take a stab at this. For read-only data, it does not matter. You can have as many threads reading it simultaneously as you want. The same goes for static methods that return a result without altering the state of anything. That eliminates a lot of code from being a potential problem area.
What you need to focus on are values that can change (mutable values). Outside of EOF and WOComponents, I don't find that I have a lot of those. The central tenant of thread safety is that you don't want one thread to be changing the value while another one reads it (or, worse, changes it!). Using synchronized methods is the most common / simple way of preventing simultaneous access. You could also use some of classes in Foundation (and probably other things) but I'm going to leave that alone. I'll stick with what I know. The best practice for this is to make the shared value private and make all methods the read or write that value synchronized. Really, it's not that hard.
OK, so where do we have to watch out for this? There are two big danger areas to watch out for. One is Application. The Application object is shared by everything and easily accessed. If you add any mutable values to Application, then you must provide synchronized methods to access them. If the values are set during the constructor and only read thereafter, you need do nothing as they are effectively read only values. The second danger area is static variables in any of your classes. Find the ones that can change and add synchronized methods to access them.
WOSession could be the third problem area except that WO strictly enforces serialized access to sessions via the check-out/check-in mechanism of WOSessionStore. Generally you don't need to worry about session level values when making your application thread safe. There are two exceptions to this. One is the above mentioned static values. Serialized session access does not mean you can disregard the need to provide for synchronized access to these. The second situation should be rare. If you are creating your own threads and a thread has a reference to a session (or any part of a session, like the defaultEditingContext) then you need to be concerned about concurrent access. I'd only do this as a last resort and do it very carefully at that. WO is not expecting multi-threaded access.
Like WOSession, WOComponents whether stateless or regular, are pretty much safe. Session's own their components and extra instances of stateless components are created to keep the threads separate. Other than static values you have to be doing something very funky to get into trouble here. Dynamic elements have to be threadsafe, but if you stick to the WOAssociation method of accessing values and don't add any instance variables to your WODynamicElement subclass you will be fine.
You will notice that I have not mentioned EOEnterpriseObjects. Needless to say (I hope) static values need to be handled as always. Other than that, each EOEditingContext has its own instance of the EO so as long as your EC is locked you are safe.
I think that is it. It sounds daunting when you go to make an application threadsafe, but once you get into it there is usually little that needs to be done.
Chuck
On Feb 7, 2005, at 2:01 PM, Kieran Kelleher wrote:
I understand locking and unlocking EOEditingContexts, and I'm sorry if this is a basic java question, but I struggle with the phrase "make sure your application is thread-safe". I've read about it here and there (including Chuck's mention in page 193 with respect to Dynamic Elements), but still not sure how being "thread-safe" affects my WOComponent subclasses, static utility classes, etc. Are there any guidelines on what/where thread-safe design should be used in the context of a WebObjects Application, Session, Component, etc.?
Josh Marker says "it's not worth the bother" in page 318 of his book! (besides correctly using WOLongResponsePage which he does illustrate)
Is there a "practical" illustration of a situation in a WO 5.2.3 app showing where/how thread safe design would be implemented?
Regards, Kieran
Well, OK, I'll take a stab at this. For read-only data, it does not matter. You can have as many threads reading it simultaneously as you want. The same goes for static methods that return a result without altering the state of anything. That eliminates a lot of code from being a potential problem area.
What you need to focus on are values that can change (mutable values). Outside of EOF and WOComponents, I don't find that I have a lot of those. The central tenant of thread safety is that you don't want one thread to be changing the value while another one reads it (or, worse, changes it!). Using synchronized methods is the most common / simple way of preventing simultaneous access. You could also use some of classes in Foundation (and probably other things) but I'm going to leave that alone. I'll stick with what I know. The best practice for this is to make the shared value private and make all methods the read or write that value synchronized. Really, it's not that hard.
OK, so where do we have to watch out for this? There are two big danger areas to watch out for. One is Application. The Application object is shared by everything and easily accessed. If you add any mutable values to Application, then you must provide synchronized methods to access them. If the values are set during the constructor and only read thereafter, you need do nothing as they are effectively read only values. The second danger area is static variables in any of your classes. Find the ones that can change and add synchronized methods to access them.
WOSession could be the third problem area except that WO strictly enforces serialized access to sessions via the check-out/check-in mechanism of WOSessionStore. Generally you don't need to worry about session level values when making your application thread safe. There are two exceptions to this. One is the above mentioned static values. Serialized session access does not mean you can disregard the need to provide for synchronized access to these. The second situation should be rare. If you are creating your own threads and a thread has a reference to a session (or any part of a session, like the defaultEditingContext) then you need to be concerned about concurrent access. I'd only do this as a last resort and do it very carefully at that. WO is not expecting multi-threaded access.
Like WOSession, WOComponents whether stateless or regular, are pretty much safe. Session's own their components and extra instances of stateless components are created to keep the threads separate. Other than static values you have to be doing something very funky to get into trouble here. Dynamic elements have to be threadsafe, but if you stick to the WOAssociation method of accessing values and don't add any instance variables to your WODynamicElement subclass you will be fine.
You will notice that I have not mentioned EOEnterpriseObjects. Needless to say (I hope) static values need to be handled as always. Other than that, each EOEditingContext has its own instance of the EO so as long as your EC is locked you are safe.
I think that is it. It sounds daunting when you go to make an application threadsafe, but once you get into it there is usually little that needs to be done.
Chuck
On Feb 7, 2005, at 2:01 PM, Kieran Kelleher wrote:
I understand locking and unlocking EOEditingContexts, and I'm sorry if this is a basic java question, but I struggle with the phrase "make sure your application is thread-safe". I've read about it here and there (including Chuck's mention in page 193 with respect to Dynamic Elements), but still not sure how being "thread-safe" affects my WOComponent subclasses, static utility classes, etc. Are there any guidelines on what/where thread-safe design should be used in the context of a WebObjects Application, Session, Component, etc.?
Josh Marker says "it's not worth the bother" in page 318 of his book! (besides correctly using WOLongResponsePage which he does illustrate)
Is there a "practical" illustration of a situation in a WO 5.2.3 app showing where/how thread safe design would be implemented?
Regards, Kieran
Posted: Tuesday - February 15, 2005 at 07:45 AM
Quick Links
Statistics
Total entries in this blog:
Total entries in this category:
Published On: Dec 29, 2008 02:27 PM
Total entries in this category:
Published On: Dec 29, 2008 02:27 PM