Thank you for replying, but I would appreciate it if you could expand on your explanation. Here is my original post:
Actually, the data that I am modifying requires a transaction and > synchronization. It increments a counter stored in the database. So, I > have to do a select to get the current value, increment the counter, and > then insert the new value. So if two threads are accessing it at the same > time, the counter will not be properly incremented. What's puzzling is that > method level synchronization does not work while synchronizing on a block of > code inside a method works. > Regardless of what persistence mechanism I use (i.e. Hibernate, EJB, etc), I have to synchronize on the method that increments the counter stored in the database. I can't avoid this due to business logic. Please let me know if there is alternative to synchronization. Thanks, Malia -----Original Message----- From: QM [mailto:[EMAIL PROTECTED] Sent: Thursday, September 30, 2004 3:01 PM To: Tomcat Users List Subject: Re: method level synchronization doesn't work On Thu, Sep 30, 2004 at 01:14:26PM -0400, Malia Noori wrote: : I thought Tomcat instantiates only 1 instance of JSP servlet to handle all : requests. Isn't that the reason why it's not suggested to have instance : variables? Close, but not quite. ;) The servlet spec permits a container to create as many instances of a servlet class as it sees fit. The same goes for creating and destroying a servlet object several times over a context (webapp) lifetime. That said, a servlet's main methods -- doGet(), doPost(), service() -- may be called concurrently for the same servlet object. These methods are thus meant to be thread-safe, and as such they shouldn't modify object instance variables. (It's fine to call such variables, as long as they are read-only or at least treated as such.) : If it is the case that 2 instance of JSP servlets gets created : to handle each request, what's the best object to synchronize on? I missed your original post, so I can say only this: when you find yourself painted into a corner, it's time to revisit the design stage. -QM -- software -- http://www.brandxdev.net tech news -- http://www.RoarNetworX.com --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
