Pete, There are a few objects in Java that are synchronized, such as the Vector object, but for the most part, synchronization is left up to the individual developer. My understanding of why this was done was for performance reasons (though someone from Sun would be more qualified to expand upon the reasons for this then I).
Basically, you have one "instantiated" copy of your class object in memory. If you were to synchronize one of the methods in your class, the keyword "synchronized" would prevent concurrent execution of that method within the object. Without the keyword "synchronized", you could have concurrent execution of the same method within that one "instantiated" object. Think of it as a group of threads running a race, with each thread that is "authorized" to execute passing a "baton" to the next waiting thread when it exits the synchronized method, so that it in turn can execute. Without the use of the keyword "synchronized", all the threads could be concurrently executing the same method of the same class at the same time. >From a performance standpoint, it is much better to consider synchronizing only the necessary methods in a class or segment of code, vs. synchronizing the entire class object. By synchronizing the entire class or object, such as a Hashtable, you decrease the performance of your application (only one thread can run at a time), and if your not careful, you can sometimes run the risk of threadlock. As a separate note, if you do not want to worry about synchronizing your objects, you can set the jsp page directive in a JSP page to false (ie, <%@ page isThreadSafe="false" %>). BUT, by doing this, it is my understanding that you are in essence creating one instantiation of each object (including your JSP page) for every user, NOT imposing synchronization on the objects, which can not only lead to performance problems, but to memory problems as well. Hope this information helps!!!! Celeste -----Original Message----- From: Pete Freitag [mailto:[EMAIL PROTECTED]] Sent: Tuesday, March 12, 2002 4:45 PM To: JRun-Talk Subject: RE: Do application variables need locking? Yeah I sort of assumed it was as well. Do any Servlet Implementations (such as JRun) synchronize their implementation of the HttpSession interface? it would probably be very easy to just declare the hashtable for the attributes as synchronized. The same for the ServletContext/application implementation? _____________________________________________ Pete Freitag ([EMAIL PROTECTED]) CTO, CFDEV.COM ColdFusion Developer Resources http://www.cfdev.com/ -----Original Message----- From: Drew Falkman [mailto:[EMAIL PROTECTED]] Sent: Tuesday, March 12, 2002 5:25 PM To: JRun-Talk Subject: RE: Do application variables need locking? That's a good question - I actually thought that it was for a while. I do know that synchronization basically kills the ability to scale. It's single threaded... -Drew Falkman Author, JRun Web Application Construction Kit http://www.drewfalkman.com/books/0789726009/ -----Original Message----- From: Pete Freitag [mailto:[EMAIL PROTECTED]] Sent: Tuesday, March 12, 2002 2:26 PM To: JRun-Talk Subject: RE: Do application variables need locking? Drew, Why isn't the session object (HttpSession) just synchronized in the servlet API? I can't think of a reason why it shouldn't be (performance?). _____________________________________________ Pete Freitag ([EMAIL PROTECTED]) CTO, CFDEV.COM ColdFusion Developer Resources http://www.cfdev.com/ -----Original Message----- From: Drew Falkman [mailto:[EMAIL PROTECTED]] Sent: Tuesday, March 12, 2002 4:49 PM To: JRun-Talk Subject: RE: Do application variables need locking? Hey Nick- In Java, to protect session and application variables from multithreading issues, you need to use synchronization. A good way to do this is to use JavaBeans components to store your session and application data. Then within your bean, you can use the synchronized keyword to synchronize your objects and methods. For example, if you have a bean called ShoppingCart which stores a users shopping cart information in an object called cartItems with an add() method, you could do this: synchronized (cartItems) { cartItems.add(item,price) } The key is that you want to synchronize your object when you make changes (just as you would do with cflock). Beans allows you to do this fairly easily. Then just store the bean in application or session scope. -Drew Falkman Author, JRun Web Application Construction Kit http://www.drewfalkman.com/books/0789726009/ -----Original Message----- From: Nick de Voil [mailto:[EMAIL PROTECTED]] Sent: Tuesday, March 12, 2002 12:19 PM To: JRun-Talk Subject: Do application variables need locking? In ColdFusion, an application variable needs to be locked while it's being accessed, to prevent one user writing to it when another is reading, giving indeterminate results or worse. Do we need to do something similar with JRun? I want to keep a set of application parameters in an application object for reading frequently by many pages, but I also want to have a feature allowing these parameters to be changed. Thanks Nick ______________________________________________________________________ This list and all House of Fusion resources hosted by CFHosting.com. The place for dependable ColdFusion Hosting. Archives: http://www.mail-archive.com/[email protected]/ Unsubscribe: http://www.houseoffusion.com/index.cfm?sidebar=lists
