> -----Original Message----- > From: A mailing list about Java Server Pages specification and reference > [mailto:[EMAIL PROTECTED]]On Behalf Of Amit Ghaste > Sent: Saturday, March 15, 2003 5:02 PM > To: [EMAIL PROTECTED] > Subject: Re: stupid question > > > vikramjit, I think he meant it in relevance to JSP.
Did he? Coz i thought he said static variables and methods. Oops. But why in jsp, put in bean, makes life much easier and follow the steps mentioned below. > > correct me if I am wrong Roldan, but did u mean declaring static variables > and/or static methods declared in a jsp page... > > if so no, you will need to implement synchronization... consider > performance > and benefits of the approach as well. Yups thats true.. Since jsp's are not thread safe and many users can access them. > > -----Original Message----- > From: A mailing list about Java Server Pages specification and reference > [mailto:[EMAIL PROTECTED]]On Behalf Of Vikramjit Singh > Sent: Tuesday, February 18, 2003 12:13 AM > To: [EMAIL PROTECTED] > Subject: Re: stupid question > > > Rather this is a very interesting question but not related to jsp > specifically. > In one simple word the answer is yes you can lock a static variable. > First, any member variable that you wish to make thread safe must be > declared private. Consider the following code: > > public class MyPoint > { > public int x; > public int y; > > public int getX() > { > return x; > } > public int getY() > { > return y; > } > public synchronized setX(int x) > { > this.x = x; > } > public synchronized getY(int y) > { > this.y = y; > } > } > If this were an ideal world, everyone would set x and y by calling setX() > and setY(), respectively. However, we all know that someone will > come along > and set x or y directly, since we defined the members as public. And since > we defined x and y as public, it is reasonable for someone to > come along and > access the variables directly. If we didn't want someone to access the > members directly, we shouldn't have declared them as public in the first > place! The only way to guarantee that threads will access x and y > safely is > to declare them as private and provide synchronized access. > Nothing changes when you declare a member static. If you don't want some > thread to come along and bypass your careful synchronization, > don't declare > the member public or protected. > Now, the question remains: how do we lock the member? Sometimes I > think that > part of the confusion around synchronization stems from a misunderstanding > of what actually happens when you call synchronized(some_object). Calling > synchronized on some_object does not prevent access to > some_object. Instead, > you must think of synchronized as a request to open a lock around > some piece > of code for your thread. some_object is the lock that you wish to have > access to. Only one thread may hold a specific lock at any one time. > Making a static member thread safe is fairly simple once you > understand what > really happens when you call synchronized. Here is a template to follow > (there are many more ways to do it, though): > > class Safe { > ... other class definitions ... > private static <type> var; > > public final synchronized static setVar(<type> val) > { > var = val; > } > } > As a second option, you can also synchronize within the method. Which > approach you take will depend upon your code. However, in this example, > either way is equivalent, since a synchronized static method > grabs the lock > on the class. You would use the second option if you were doing a lot of > processing inside of the method. That way you only synchronize > when you have > to -- thus improving performance. > You would need to use synchronization within the method if you didn't want > to declare setVar() static. A nonstatic method declared as synchronized > locks on the instance, not the class. So, if you had more than > one instance, > the member would no longer be thread safe. > > -----Original Message----- > From: A mailing list about Java Server Pages specification and reference > [mailto:[EMAIL PROTECTED]]On Behalf Of ROLDAN, Gabriel raul > Sent: Monday, February 17, 2003 6:59 PM > To: [EMAIL PROTECTED] > Subject: stupid question > > > excuse this stupid and out of topic question, but.. ¿are static > methods and > fields synchronized? > > ========================= > To unsubscribe: mailto [EMAIL PROTECTED] with body: "signoff > JSP-INTEREST". > For digest: mailto [EMAIL PROTECTED] with body: "set JSP-INTEREST > DIGEST". > > Some relevant archives, FAQs and Forums on JSPs can be found at: > > http://java.sun.com/products/jsp > http://archives.java.sun.com/jsp-interest.html > http://forums.java.sun.com > http://www.jspinsider.com > > ================================================================== > ========= > To unsubscribe: mailto [EMAIL PROTECTED] with body: "signoff > JSP-INTEREST". > For digest: mailto [EMAIL PROTECTED] with body: "set JSP-INTEREST > DIGEST". > > Some relevant archives, FAQs and Forums on JSPs can be found at: > > http://java.sun.com/products/jsp > http://archives.java.sun.com/jsp-interest.html > http://forums.java.sun.com > http://www.jspinsider.com > > ================================================================== > ========= > To unsubscribe: mailto [EMAIL PROTECTED] with body: "signoff > JSP-INTEREST". > For digest: mailto [EMAIL PROTECTED] with body: "set > JSP-INTEREST DIGEST". > > Some relevant archives, FAQs and Forums on JSPs can be found at: > > http://java.sun.com/products/jsp > http://archives.java.sun.com/jsp-interest.html > http://forums.java.sun.com > http://www.jspinsider.com =========================================================================== To unsubscribe: mailto [EMAIL PROTECTED] with body: "signoff JSP-INTEREST". For digest: mailto [EMAIL PROTECTED] with body: "set JSP-INTEREST DIGEST". Some relevant archives, FAQs and Forums on JSPs can be found at: http://java.sun.com/products/jsp http://archives.java.sun.com/jsp-interest.html http://forums.java.sun.com http://www.jspinsider.com
