> Metaphorically speaking, it acts as a lock that only lets one thread use > it (the current one that reached the statement). All other threads are > put in waiting until the first thread is done. This is important with > servlets since they are multithreaded and you want to make sure other > threads aren't mutating the data you [the current thread] are working > with.
Correct, but it is only important if the Objects you are accessing (mutating data on) can be referenced outside of the current HttpServletRequest or HttpSession objects. Each servlet thread has its own unique HttpSession (and unique HttpServletRequest objects, as requests come in), not accessible from other threads (through any normal means), and thus any new objects you create and store there are in no danger of being accessed by other threads. Adding synchronized code blocks around manipulations of these objects is unnecessary and will result in performance hits as well as code clutter. You WILL need to use synchronized code blocks w/ Servlets for manipulating data in static or singleton Objects, or Objects that are obtained from some common environment and thus accessible to all Servlet threads. Value objects you store in the session or request should never fall into either of these categories. peace, Joe > > Jacob Hookom > CS Student > University of Wisconsin, Eau Claire > =================================== > http://www.swanked.net > you're not hip enough yet > > -----Original Message----- > From: Kamholz, Keith (corp-staff) USX [mailto:[EMAIL PROTECTED]] > Sent: Wednesday, July 17, 2002 12:29 PM > To: 'Struts Users Mailing List' > Subject: RE: Pre-Populating Form > > This is probably a stupid question, but I've never used a synchronized > block > before. What exactly does it do? > > ~ Keith > http://www.buffalo.edu/~kkamholz > > > > -----Original Message----- > From: Joseph Barefoot [mailto:[EMAIL PROTECTED]] > Sent: Wednesday, July 17, 2002 1:31 PM > To: Struts Users Mailing List > Subject: RE: Pre-Populating Form > > > > -----Original Message----- > > From: Galbreath, Mark [mailto:[EMAIL PROTECTED]] > > Sent: Wednesday, July 17, 2002 11:55 AM > > To: 'Struts Users Mailing List' > > Subject: RE: Pre-Populating Form > > > > > > There are two ways: > > > > 1. Use session.setAttribute() instead and access the attribute in the > 2d > > JSP form; > > > > 2. (preferable) In your Action class, use > > > > MyActionForm myActionForm = (MyActionForm) form; > > synchronized( myActionForm) { > > myActionForm.setWhatever( request.getParameter( "updatedValue"); > > } > > > Why the synchronized block, Mark? Getting cautious after the near anal > probe at Heathrow? ;) > > > > > > and have either <bean:write> or <html:text> get the value from the > updated > > formbean. > > > > Mark > > > > -----Original Message----- > > From: Kamholz, Keith (corp-staff) USX [mailto:[EMAIL PROTECTED]] > > Sent: Wednesday, July 17, 2002 10:56 AM > > > > Hey everyone, > > I have a list of information entries on my JSP page. I have a > > link next to > > each to edit it. The link works fine, and the action knows which > > index was > > clicked. However, I need to populate the from on the following JSP > before > > the user reaches it. I'm trying to just use request.setAttribute(), > but > > it's not working, probably because request refers to the page the link > was > > on, not my form page. How do I pre-populate the form? I know that if > the > > bean was in the session, I could just set the attribute, but I'm > trying to > > figure out how to manage things in request. I looked in the archive > some, > > but didn't see anything. Any help would be greatly appreciated! > > > > ~ Keith > > > > -- > > 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]> > > -- > To unsubscribe, e-mail: > <mailto:[EMAIL PROTECTED]> > For additional commands, e-mail: > <mailto:[EMAIL PROTECTED]> > > --- > Incoming mail is certified Virus Free. > Checked by AVG anti-virus system (http://www.grisoft.com). > Version: 6.0.375 / Virus Database: 210 - Release Date: 7/10/2002 > > > --- > Outgoing mail is certified Virus Free. > Checked by AVG anti-virus system (http://www.grisoft.com). > Version: 6.0.375 / Virus Database: 210 - Release Date: 7/10/2002 > > > > -- > 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]>
