Re: Single Thread is deprecated?
On 1/9/06, Wade Chandler <[EMAIL PROTECTED]> wrote: ... > I don't know about 5.5.15, but 5.5.9 used HashMap. > The synchronization of the session object was an issue > which caused other issues and is why there should now > be synchronization on the reading as well as writing > session attributes. There was a huge discussion on > this on the list as well as a bug associated with it > which could cause finite dead locks in Tomcat if > access made the session resize while it were being > read (should be able to find it in bugzilla...bugzilla > was still being used). http://issues.apache.org/bugzilla/show_bug.cgi?id=36541 leon - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Single Thread is deprecated?
George Sexton wrote: >>-Original Message- >>From: Duan, Nick [mailto:[EMAIL PROTECTED] >>HttpSession should be implemented (it's just an interface). In fact, >>the session attributes were implemented as a Hashtable in >>tomcat, not a >>Hashmap (just double checked the latest 5.5.15 src of tomcat). As we >>all know, Hashtable already has thread sync built in. So that's why >>additional synchronization on HttpSession in tomcat is unnecessary. SVN: StandardSession.java in Tomcat 5.0.x and 4.1.x use HashMap, 5.5.x HashTable. >> > > > I believe this is a fairly recent change. There was a major thread about > this in November. In short, it was a HashMap and it got changed. > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Single Thread is deprecated?
--- Wade Chandler <[EMAIL PROTECTED]> wrote: > --- "Duan, Nick" <[EMAIL PROTECTED]> wrote: > > > Well, when I was mentioning the term user session, > I > > was discussing from > > a threading/transaction perspective, not from the > > servlet object > > perspective. It is the worker thread that > > represents a active user > > session and accesses both the session and the > > servlet object (if we want > > to be precise). > > > > Chuck was right. It is possible to have one > client > > (single browser) to > > start two concurrent sessions at the same time, > both > > eligible to access > > the same HttpSession object. Therefore, it looks > > like synchronization > > is necessary from the spec. However, the spec > does > > not define how > > HttpSession should be implemented (it's just an > > interface). In fact, > > the session attributes were implemented as a > > Hashtable in tomcat, not a > > Hashmap (just double checked the latest 5.5.15 src > > of tomcat). As we > > all know, Hashtable already has thread sync built > > in. So that's why > > additional synchronization on HttpSession in > tomcat > > is unnecessary. > > > > ND > I don't know about 5.5.15, but 5.5.9 used HashMap. > The synchronization of the session object was an > issue > which caused other issues and is why there should > now > be synchronization on the reading as well as writing > session attributes. There was a huge discussion on > this on the list as well as a bug associated with it > which could cause finite dead locks in Tomcat if > access made the session resize while it were being > read (should be able to find it in > bugzilla...bugzilla > was still being used). Session has to be > synchronized > anyways, so regardless of misintrepretation/correct > interpretation of the specification arguments it > would > make sense for these calls to be synchronized by > what > ever server is implementing the specification. I'm > saying: If all developers have to synchronize access > to all session access then would it not make sense > for > things to be synchronized as they currently are...at > the server level? All scopes which would need > synchronization should really be handled at the > server > level (application and session). > > The tomcat source code should be synchronizing these > things now. At the time it wasn't talked about, but > the application level scope was not being > synchronized > when I looked through the source code when the > synchronization bug mentioned above was being > discussed. I don't know if this has changed or not > (I > was hoping ... considering the needless long overly > exhaustive discussion that had to occur to get an > obvious bug changed back to the correct > behaviour...it > was once synchronized correctly before it was > brokenthat the other pieces would be seen and > fixed as well as they would cause the same dead lock > behaviour as session access could depending on what > happened when the application scope was accessed > does > a read occur when a write occurs or a write at > certain > points in the resize.). Just to clarify now before > a > discussion starts again on this topic: It matters > these things are taken care of at the server level > in > one place or another as JSP/EL are hard to > synchronize > without breaking their use case (not to use java > code > within them). I mean, if someone knows how to > synchronize access to the session or application > scopes (use that term to represent accessing the > session from all other places and tags it can be > accessed) when using EL or setting/getting a bean in > a > JSP without a specialized tag library or wrapping in > java code then please share, but I think I'm asking > an > unanswerable quesiton ;-) > > I wouldn't imagine that the source code is using > Hashtable as Hashtable does not allow null values, > and > would have changed the currently used session > access. > Were you looking at the file: > $TOMCAT_SRC/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/session/StandardSession.java > in your source? Ok, so after I wrote that I checked the latest sourceit is a Hashtable. When did the behaviour change that a null attribute could not be used. I could have swore I remember using null attributes in sessions...oh well, the way it is handled in setAttribute works well. Remove it so you can always check to see if it is set or not with a getAttribute call. So yeah, that should do it. I guess I'll go ahead and check the SessionContext as well. ... Wade - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Single Thread is deprecated?
--- "Duan, Nick" <[EMAIL PROTECTED]> wrote: > Well, when I was mentioning the term user session, I > was discussing from > a threading/transaction perspective, not from the > servlet object > perspective. It is the worker thread that > represents a active user > session and accesses both the session and the > servlet object (if we want > to be precise). > > Chuck was right. It is possible to have one client > (single browser) to > start two concurrent sessions at the same time, both > eligible to access > the same HttpSession object. Therefore, it looks > like synchronization > is necessary from the spec. However, the spec does > not define how > HttpSession should be implemented (it's just an > interface). In fact, > the session attributes were implemented as a > Hashtable in tomcat, not a > Hashmap (just double checked the latest 5.5.15 src > of tomcat). As we > all know, Hashtable already has thread sync built > in. So that's why > additional synchronization on HttpSession in tomcat > is unnecessary. > > ND I don't know about 5.5.15, but 5.5.9 used HashMap. The synchronization of the session object was an issue which caused other issues and is why there should now be synchronization on the reading as well as writing session attributes. There was a huge discussion on this on the list as well as a bug associated with it which could cause finite dead locks in Tomcat if access made the session resize while it were being read (should be able to find it in bugzilla...bugzilla was still being used). Session has to be synchronized anyways, so regardless of misintrepretation/correct interpretation of the specification arguments it would make sense for these calls to be synchronized by what ever server is implementing the specification. I'm saying: If all developers have to synchronize access to all session access then would it not make sense for things to be synchronized as they currently are...at the server level? All scopes which would need synchronization should really be handled at the server level (application and session). The tomcat source code should be synchronizing these things now. At the time it wasn't talked about, but the application level scope was not being synchronized when I looked through the source code when the synchronization bug mentioned above was being discussed. I don't know if this has changed or not (I was hoping ... considering the needless long overly exhaustive discussion that had to occur to get an obvious bug changed back to the correct behaviour...it was once synchronized correctly before it was brokenthat the other pieces would be seen and fixed as well as they would cause the same dead lock behaviour as session access could depending on what happened when the application scope was accessed does a read occur when a write occurs or a write at certain points in the resize.). Just to clarify now before a discussion starts again on this topic: It matters these things are taken care of at the server level in one place or another as JSP/EL are hard to synchronize without breaking their use case (not to use java code within them). I mean, if someone knows how to synchronize access to the session or application scopes (use that term to represent accessing the session from all other places and tags it can be accessed) when using EL or setting/getting a bean in a JSP without a specialized tag library or wrapping in java code then please share, but I think I'm asking an unanswerable quesiton ;-) I wouldn't imagine that the source code is using Hashtable as Hashtable does not allow null values, and would have changed the currently used session access. Were you looking at the file: $TOMCAT_SRC/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/session/StandardSession.java in your source? Wade - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Single Thread is deprecated?
> -Original Message- > From: Duan, Nick [mailto:[EMAIL PROTECTED] > Sent: Monday, January 09, 2006 11:41 AM > To: Tomcat Users List > Subject: RE: Single Thread is deprecated? > > HttpSession should be implemented (it's just an interface). In fact, > the session attributes were implemented as a Hashtable in > tomcat, not a > Hashmap (just double checked the latest 5.5.15 src of tomcat). As we > all know, Hashtable already has thread sync built in. So that's why > additional synchronization on HttpSession in tomcat is unnecessary. > I believe this is a fairly recent change. There was a major thread about this in November. In short, it was a HashMap and it got changed. George Sexton MH Software, Inc. http://www.mhsoftware.com/ Voice: 303 438 9585 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Single Thread is deprecated?
Well, when I was mentioning the term user session, I was discussing from a threading/transaction perspective, not from the servlet object perspective. It is the worker thread that represents a active user session and accesses both the session and the servlet object (if we want to be precise). Chuck was right. It is possible to have one client (single browser) to start two concurrent sessions at the same time, both eligible to access the same HttpSession object. Therefore, it looks like synchronization is necessary from the spec. However, the spec does not define how HttpSession should be implemented (it's just an interface). In fact, the session attributes were implemented as a Hashtable in tomcat, not a Hashmap (just double checked the latest 5.5.15 src of tomcat). As we all know, Hashtable already has thread sync built in. So that's why additional synchronization on HttpSession in tomcat is unnecessary. ND -Original Message- From: GB Developer [mailto:[EMAIL PROTECTED] Sent: Friday, January 06, 2006 6:33 PM To: 'Tomcat Users List' Subject: RE: Single Thread is deprecated? > -Original Message- > From: Duan, Nick [mailto:[EMAIL PROTECTED] > Sent: Friday, January 06, 2006 5:14 PM > To: Tomcat Users List > Subject: RE: Single Thread is deprecated? > > Typo due to my laziness. I knew someone was going to catch > this. Actually the sentence should read: ... because there > is only one servlet that is active during a single user session. > > In other words, there is no way a single user session > (represented by a worker thread) can access more than one > servlet at a time. Yah, I don't think that's right either, and besides that, it's a little backwards to describe it as you have. A sessions doesn't so much access servlets, as the servlets (more than one, regardless of their single-threadness) can access a single Session at once. Sessions are (never?) thread-safe. Which is perhaps one reason why SingleThreadModel was deprecated. People thought by using that interface that they would never have to worry about synch issues again. Even if you have nothing but singleThread servlets, that only prevents concurrent access to that servlet. Neither singleThread servlets nor any other mechanism I'm aware of can prevents concurrent access to a single Session object. Perhaps Remy will weigh in again with so many wildly varying 'opinions' ;) - 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]
Re: Single Thread is deprecated?
Michael Echerer wrote: > Dakota Jack wrote: > >>Actually, any class with only local variables is always thread safe. >> > > True for locals, but we were talking about instance&class variables, > actually. You may of course still have instance&class variables... ThreadLocals (usually static) work fine ;-) http://java.sun.com/j2se/1.4.2/docs/api/java/lang/ThreadLocal.html Cheers, Michael > > > - > 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]
Re: Single Thread is deprecated?
Dakota Jack wrote: > Actually, any class with only local variables is always thread safe. > True for locals, but we were talking about instance&class variables, actually. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Single Thread is deprecated?
Actually, any class with only local variables is always thread safe. On 1/6/06, Michael Echerer <[EMAIL PROTECTED]> wrote: > > Duan, Nick wrote: > > HttpServlet is inherently thread-safe as long as you don't use any > > instance and class variables in your code. There is also no need to > > sync around the session object, because there is only one servlet that > > is active at a time. The only sync you have to do is with app context > > objects. > How can you guarantee that only one servlet is active at a time? Tomcat > by default has many connector threads that could simultaneously handle > concurrent requests to the same servlet or different servlets that all > could work with the same sessionid session objects. Without > SingleThreadModel this servlet won't be pooled, hence all requests would > have to be serialized to make this work, which is obviously not an > option for performance reasons as the spec says (e.g. regarding servlet > lifecycle and synchronized service methods) > BTW, if only one servlet would be active at a time, your advice not to > use instance/class variables would not be of any use, as under this > assumption no concurrency issues while accessing those variables could > occur. However it's valid. > It should be quite easy to write a simple test jsp using a session and > containing e.g. image links to a servlet that manipulates session > content, each time called. Due to most browsers behaviour to request > many images at the same time and Tomcats connector threads, I wouldn't > bet on this, if you put this under load and log results... > > > > If you want to sync on your DB resource, you will have bottleneck > > problems with DB connections. The best solution is to use a DB > > connection pool which is more scalable. > > > DB connections pools are a good idea (e.g. to avoid connection opening > times that take a few hundred ms with most DBs, eventhough neglectable > for others). Nevertheless depending on the kind of transactions done, > setting an appropriate transaction isolation level is just as important > as doing other syncs. If you just read from the DB you can stick to the > default level, but e.g. for a booking & reservation system, I wouldn't > trust read-committed, when doing lookups, inserts, updates wildly mixed > in one transaction. Could easily happen that someone else booked your > trip then, eventhough you got the confirmation... ;-) > > Cheers, > Michael > > ND > > > > -Original Message- > > From: Michael Echerer [mailto:[EMAIL PROTECTED] > > Sent: Friday, January 06, 2006 11:52 AM > > To: Tomcat Users List > > Subject: Re: Single Thread is deprecated? > > > > Christian Stalp wrote: > > > >>Hello out there, > >>I want to build a servelt which access a database. To avoid > >>race-conditions and to realize synchronous access, I decited to make a > >>"Singe Thread" Servlet. But Eclipse told me that this is no longer a > >>usable code. > > > > Usually the best solution is to synchronize just the part that accesses > > the single resource (the DB) instead of using single thread. > > > > In worst case you won't even achieve what you want using single thread > > mode because according to the servlet specification servlet containers > > are free to pool servlets, if it implements SingleThreadModel. Hence you > > could have multiple pooled instances that be no means guarantee an > > synchronized access to your database in case of simultaneous requests > > hitting different instances. > > > > So SingleThreadModel is deprecated for good reason, since servlet spec > > 2.4 and also for 2.5. You are better of synchronizing yourself. Don't > > rely on SingleThreadModel as an easy way to get around multithreading > > issues. > > > > In case you have different code parts accessing your DB or various > > clients, it might not even help to just sync one servlet. You might even > > have to set database transaction isolation level to fit your needs for > > your DB connections. Most DBs have "read-committed" by default, but it > > might be that you need isolation level up to "synchronized". Depends on > > your use case... > > > > Cheers > > Michael > > > > > >>So what can I do else? > >> > >>Thank you... > >> > >>Gruss Christian > >> > >> > >>- > >>To unsubscribe, e-mail: [EMAIL PROTECTED] > >>For additional commands, e-mail
Re: Single Thread is deprecated?
GB Developer wrote: > > Sessions are (never?) thread-safe. Which is perhaps one reason why > SingleThreadModel was deprecated. People thought by using that interface > that they would never have to worry about synch issues again. The servlet spec 2.5 draft says in SRV 2.2.1. (should be similar in 2.4.). Even spec 2.3 had this warning note eventhough in 2.3. SingleThreadModel wasn't deprecated: "Objects that are accessible to more than one servlet instance at a time, such as instances of HttpSession, may be available at any particular time to multiple servlets, including those that implement SingleThreadModel." So this was one of the reasons to deprecate this. Chuck and you are right. I described ways to achieve concurrent access to one session using multiple servlets (or multithreaded access). Just think of frames or the infamous IE double submit problem for more examples. Cheers, Michael - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Single Thread is deprecated?
> -Original Message- > From: Duan, Nick [mailto:[EMAIL PROTECTED] > Sent: Friday, January 06, 2006 5:14 PM > To: Tomcat Users List > Subject: RE: Single Thread is deprecated? > > Typo due to my laziness. I knew someone was going to catch > this. Actually the sentence should read: ... because there > is only one servlet that is active during a single user session. > > In other words, there is no way a single user session > (represented by a worker thread) can access more than one > servlet at a time. Yah, I don't think that's right either, and besides that, it's a little backwards to describe it as you have. A sessions doesn't so much access servlets, as the servlets (more than one, regardless of their single-threadness) can access a single Session at once. Sessions are (never?) thread-safe. Which is perhaps one reason why SingleThreadModel was deprecated. People thought by using that interface that they would never have to worry about synch issues again. Even if you have nothing but singleThread servlets, that only prevents concurrent access to that servlet. Neither singleThread servlets nor any other mechanism I'm aware of can prevents concurrent access to a single Session object. Perhaps Remy will weigh in again with so many wildly varying 'opinions' ;) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Single Thread is deprecated?
> From: Duan, Nick [mailto:[EMAIL PROTECTED] > Subject: RE: Single Thread is deprecated? > > Typo due to my laziness. I knew someone was going to catch this. > Actually the sentence should read: ... because there is only one > servlet that is active during a single user session. Are you really sure about that? I'm under the impression that a client (browser) can have multiple concurrent connections and requests to a server under the same session; each connection could run different servlets simultaneously under the same session. Unless there's some serialization going on somewhere else... - Chuck THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus for use only by the intended recipient. If you received this in error, please contact the sender and delete the e-mail and its attachments from all computers. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Single Thread is deprecated?
Typo due to my laziness. I knew someone was going to catch this. Actually the sentence should read: ... because there is only one servlet that is active during a single user session. In other words, there is no way a single user session (represented by a worker thread) can access more than one servlet at a time. The deprecation of SingleThreadModel API is due to its unnecessity and the possibility of confusions on how to use it. If multiple concurrent threads access a method of an object that does not use any class or instance variables, like the most cases in doGet and doPost of HttpServlet, why bother to sync them? ND -Original Message- From: Michael Echerer [mailto:[EMAIL PROTECTED] Sent: Friday, January 06, 2006 5:44 PM To: Tomcat Users List Subject: Re: Single Thread is deprecated? Duan, Nick wrote: > HttpServlet is inherently thread-safe as long as you don't use any > instance and class variables in your code. There is also no need to > sync around the session object, because there is only one servlet that > is active at a time. The only sync you have to do is with app context > objects. How can you guarantee that only one servlet is active at a time? Tomcat by default has many connector threads that could simultaneously handle concurrent requests to the same servlet or different servlets that all could work with the same sessionid session objects. Without SingleThreadModel this servlet won't be pooled, hence all requests would have to be serialized to make this work, which is obviously not an option for performance reasons as the spec says (e.g. regarding servlet lifecycle and synchronized service methods) BTW, if only one servlet would be active at a time, your advice not to use instance/class variables would not be of any use, as under this assumption no concurrency issues while accessing those variables could occur. However it's valid. It should be quite easy to write a simple test jsp using a session and containing e.g. image links to a servlet that manipulates session content, each time called. Due to most browsers behaviour to request many images at the same time and Tomcats connector threads, I wouldn't bet on this, if you put this under load and log results... > > If you want to sync on your DB resource, you will have bottleneck > problems with DB connections. The best solution is to use a DB > connection pool which is more scalable. > DB connections pools are a good idea (e.g. to avoid connection opening times that take a few hundred ms with most DBs, eventhough neglectable for others). Nevertheless depending on the kind of transactions done, setting an appropriate transaction isolation level is just as important as doing other syncs. If you just read from the DB you can stick to the default level, but e.g. for a booking & reservation system, I wouldn't trust read-committed, when doing lookups, inserts, updates wildly mixed in one transaction. Could easily happen that someone else booked your trip then, eventhough you got the confirmation... ;-) Cheers, Michael > ND > > -Original Message- > From: Michael Echerer [mailto:[EMAIL PROTECTED] > Sent: Friday, January 06, 2006 11:52 AM > To: Tomcat Users List > Subject: Re: Single Thread is deprecated? > > Christian Stalp wrote: > >>Hello out there, >>I want to build a servelt which access a database. To avoid >>race-conditions and to realize synchronous access, I decited to make a >>"Singe Thread" Servlet. But Eclipse told me that this is no longer a >>usable code. > > Usually the best solution is to synchronize just the part that accesses > the single resource (the DB) instead of using single thread. > > In worst case you won't even achieve what you want using single thread > mode because according to the servlet specification servlet containers > are free to pool servlets, if it implements SingleThreadModel. Hence you > could have multiple pooled instances that be no means guarantee an > synchronized access to your database in case of simultaneous requests > hitting different instances. > > So SingleThreadModel is deprecated for good reason, since servlet spec > 2.4 and also for 2.5. You are better of synchronizing yourself. Don't > rely on SingleThreadModel as an easy way to get around multithreading > issues. > > In case you have different code parts accessing your DB or various > clients, it might not even help to just sync one servlet. You might even > have to set database transaction isolation level to fit your needs for > your DB connections. Most DBs have "read-committed" by default, but it > might be that you need isolation level up to "synchronized". Depends on > your use case... > > Cheers > Michael > >
Re: Single Thread is deprecated?
Duan, Nick wrote: > HttpServlet is inherently thread-safe as long as you don't use any > instance and class variables in your code. There is also no need to > sync around the session object, because there is only one servlet that > is active at a time. The only sync you have to do is with app context > objects. How can you guarantee that only one servlet is active at a time? Tomcat by default has many connector threads that could simultaneously handle concurrent requests to the same servlet or different servlets that all could work with the same sessionid session objects. Without SingleThreadModel this servlet won't be pooled, hence all requests would have to be serialized to make this work, which is obviously not an option for performance reasons as the spec says (e.g. regarding servlet lifecycle and synchronized service methods) BTW, if only one servlet would be active at a time, your advice not to use instance/class variables would not be of any use, as under this assumption no concurrency issues while accessing those variables could occur. However it's valid. It should be quite easy to write a simple test jsp using a session and containing e.g. image links to a servlet that manipulates session content, each time called. Due to most browsers behaviour to request many images at the same time and Tomcats connector threads, I wouldn't bet on this, if you put this under load and log results... > > If you want to sync on your DB resource, you will have bottleneck > problems with DB connections. The best solution is to use a DB > connection pool which is more scalable. > DB connections pools are a good idea (e.g. to avoid connection opening times that take a few hundred ms with most DBs, eventhough neglectable for others). Nevertheless depending on the kind of transactions done, setting an appropriate transaction isolation level is just as important as doing other syncs. If you just read from the DB you can stick to the default level, but e.g. for a booking & reservation system, I wouldn't trust read-committed, when doing lookups, inserts, updates wildly mixed in one transaction. Could easily happen that someone else booked your trip then, eventhough you got the confirmation... ;-) Cheers, Michael > ND > > -Original Message- > From: Michael Echerer [mailto:[EMAIL PROTECTED] > Sent: Friday, January 06, 2006 11:52 AM > To: Tomcat Users List > Subject: Re: Single Thread is deprecated? > > Christian Stalp wrote: > >>Hello out there, >>I want to build a servelt which access a database. To avoid >>race-conditions and to realize synchronous access, I decited to make a >>"Singe Thread" Servlet. But Eclipse told me that this is no longer a >>usable code. > > Usually the best solution is to synchronize just the part that accesses > the single resource (the DB) instead of using single thread. > > In worst case you won't even achieve what you want using single thread > mode because according to the servlet specification servlet containers > are free to pool servlets, if it implements SingleThreadModel. Hence you > could have multiple pooled instances that be no means guarantee an > synchronized access to your database in case of simultaneous requests > hitting different instances. > > So SingleThreadModel is deprecated for good reason, since servlet spec > 2.4 and also for 2.5. You are better of synchronizing yourself. Don't > rely on SingleThreadModel as an easy way to get around multithreading > issues. > > In case you have different code parts accessing your DB or various > clients, it might not even help to just sync one servlet. You might even > have to set database transaction isolation level to fit your needs for > your DB connections. Most DBs have "read-committed" by default, but it > might be that you need isolation level up to "synchronized". Depends on > your use case... > > Cheers > Michael > > >>So what can I do else? >> >>Thank you... >> >>Gruss Christian >> >> >>- >>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] > > > - > 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]
RE: Single Thread is deprecated?
HttpServlet is inherently thread-safe as long as you don't use any instance and class variables in your code. There is also no need to sync around the session object, because there is only one servlet that is active at a time. The only sync you have to do is with app context objects. If you want to sync on your DB resource, you will have bottleneck problems with DB connections. The best solution is to use a DB connection pool which is more scalable. ND -Original Message- From: Michael Echerer [mailto:[EMAIL PROTECTED] Sent: Friday, January 06, 2006 11:52 AM To: Tomcat Users List Subject: Re: Single Thread is deprecated? Christian Stalp wrote: > Hello out there, > I want to build a servelt which access a database. To avoid > race-conditions and to realize synchronous access, I decited to make a > "Singe Thread" Servlet. But Eclipse told me that this is no longer a > usable code. Usually the best solution is to synchronize just the part that accesses the single resource (the DB) instead of using single thread. In worst case you won't even achieve what you want using single thread mode because according to the servlet specification servlet containers are free to pool servlets, if it implements SingleThreadModel. Hence you could have multiple pooled instances that be no means guarantee an synchronized access to your database in case of simultaneous requests hitting different instances. So SingleThreadModel is deprecated for good reason, since servlet spec 2.4 and also for 2.5. You are better of synchronizing yourself. Don't rely on SingleThreadModel as an easy way to get around multithreading issues. In case you have different code parts accessing your DB or various clients, it might not even help to just sync one servlet. You might even have to set database transaction isolation level to fit your needs for your DB connections. Most DBs have "read-committed" by default, but it might be that you need isolation level up to "synchronized". Depends on your use case... Cheers Michael > > So what can I do else? > > Thank you... > > Gruss Christian > > > - > 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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Single Thread is deprecated?
Remy Maucherat schrieb: Nice, but completely wrong. STM in Tomcat uses an instance pool which allows having a minimal impact (something like 5%), and it will perform much better than syncing, unless the said sync is trivial. The reason this is deprecated is because some people thought it would solve all their syncing problems, while it doesn't address many things (like session access). In my case the session-management will be realized by a front-servlet. This servlet accept all the input of the user. Package this input into JDOM-Objects and send this object to this "single threaded" servlet. This servlets does nothing but to access the database. Gruss Christian - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Single Thread is deprecated?
Remy Maucherat wrote: > On 1/6/06, Michael Echerer <[EMAIL PROTECTED]> wrote: > >>In worst case you won't even achieve what you want using single thread >>mode because according to the servlet specification servlet containers >>are free to pool servlets, if it implements SingleThreadModel. Hence you >>could have multiple pooled instances that be no means guarantee an >>synchronized access to your database in case of simultaneous requests >>hitting different instances. >> >>So SingleThreadModel is deprecated for good reason, since servlet spec >>2.4 and also for 2.5. You are better of synchronizing yourself. Don't >>rely on SingleThreadModel as an easy way to get around multithreading >>issues. > > > Nice, but completely wrong. STM in Tomcat uses an instance pool which > allows having a minimal impact (something like 5%), and it will > perform much better than syncing, unless the said sync is trivial. Completely wrong? Actually taken from servlet spec 2.5 draft, but I guess it's not changed since 2.4. "SRV.2.2.1 Note About The Single Thread Model The use of the SingleThreadModel interface guarantees that only one thread at a time will execute in a given servlet instance’s service method. It is important to note that this guarantee only applies to each servlet instance, since the container may choose to pool such objects. Objects that are accessible to more than one servlet instance at a time, such as instances of HttpSession, may be available at any particular time to multiple servlets, including those that implement SingleThreadModel. It is recommended that a developer take other means to resolve those issues instead of implementing this interface, such as avoiding the usage of an instance variable or synchronizing the block of the code accessing those resources. The SingleThreadModel Interface is deprecated in this version of the specification." Probably I mis-understood what "guarantee only applies to 'each' servlet instance, since the container may choose to pool such objects". In how far this is good for performance reasons, I cannot judge, never tried for above reasons. > > The reason this is deprecated is because some people thought it would > solve all their syncing problems, while it doesn't address many things > (like session access). true indeed, that's why I warned to use single thread model for an easy cure for all multithreading issues (especially if a DB access is intendend). Cheers, Michael > > -- > x > Rémy Maucherat > Developer & Consultant > JBoss Group (Europe) SàRL > x > > - > 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]
Re: Single Thread is deprecated?
On 1/6/06, Michael Echerer <[EMAIL PROTECTED]> wrote: > In worst case you won't even achieve what you want using single thread > mode because according to the servlet specification servlet containers > are free to pool servlets, if it implements SingleThreadModel. Hence you > could have multiple pooled instances that be no means guarantee an > synchronized access to your database in case of simultaneous requests > hitting different instances. > > So SingleThreadModel is deprecated for good reason, since servlet spec > 2.4 and also for 2.5. You are better of synchronizing yourself. Don't > rely on SingleThreadModel as an easy way to get around multithreading > issues. Nice, but completely wrong. STM in Tomcat uses an instance pool which allows having a minimal impact (something like 5%), and it will perform much better than syncing, unless the said sync is trivial. The reason this is deprecated is because some people thought it would solve all their syncing problems, while it doesn't address many things (like session access). -- x Rémy Maucherat Developer & Consultant JBoss Group (Europe) SàRL x - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Single Thread is deprecated?
Christian Stalp wrote: > Hello out there, > I want to build a servelt which access a database. To avoid > race-conditions and to realize synchronous access, I decited to make a > "Singe Thread" Servlet. But Eclipse told me that this is no longer a > usable code. Usually the best solution is to synchronize just the part that accesses the single resource (the DB) instead of using single thread. In worst case you won't even achieve what you want using single thread mode because according to the servlet specification servlet containers are free to pool servlets, if it implements SingleThreadModel. Hence you could have multiple pooled instances that be no means guarantee an synchronized access to your database in case of simultaneous requests hitting different instances. So SingleThreadModel is deprecated for good reason, since servlet spec 2.4 and also for 2.5. You are better of synchronizing yourself. Don't rely on SingleThreadModel as an easy way to get around multithreading issues. In case you have different code parts accessing your DB or various clients, it might not even help to just sync one servlet. You might even have to set database transaction isolation level to fit your needs for your DB connections. Most DBs have "read-committed" by default, but it might be that you need isolation level up to "synchronized". Depends on your use case... Cheers Michael > > So what can I do else? > > Thank you... > > Gruss Christian > > > - > 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]
Re: Single Thread is deprecated?
--- Christian Stalp <[EMAIL PROTECTED]> wrote: > Remy Maucherat wrote: > > >It's deprecated because it is confusing, but it is > actually very > >useful performance wise in some cases, since it > does pooling. I will > >make sure this feature remains available in the > future. > > > > > > > That means, I still can use it?! Deprecated is not > prohibited!?!! Is > there any alternative for such purposes? > > Gruss Christian Deprecated only means the feature is not guarenteed to be around in future releases, so you shouldn't be upset if one day it is gone in another version. It doesn't mean you can't use it. Sometimes APIs get deprecated before their replacements are even added (when they're getting a replacement). For a simple definition of the word: http://www.webopedia.com/TERM/D/deprecated.html Wade - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Single Thread is deprecated?
Christian Stalp wrote: Remy Maucherat wrote: It's deprecated because it is confusing, but it is actually very useful performance wise in some cases, since it does pooling. I will make sure this feature remains available in the future. That means, I still can use it?! Deprecated is not prohibited!?!! Is there any alternative for such purposes? Deprecated does not mean prohibited; it just means not recommended. Frequently this is because its functionality is being replaced by a newer method, but there can be other reasons as well. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Single Thread is deprecated?
Remy Maucherat wrote: It's deprecated because it is confusing, but it is actually very useful performance wise in some cases, since it does pooling. I will make sure this feature remains available in the future. That means, I still can use it?! Deprecated is not prohibited!?!! Is there any alternative for such purposes? Gruss Christian - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Single Thread is deprecated?
On 1/6/06, Christian Stalp <[EMAIL PROTECTED]> wrote: > Hello out there, > I want to build a servelt which access a database. To avoid > race-conditions and to realize synchronous access, I decited to make a > "Singe Thread" Servlet. But Eclipse told me that this is no longer a > usable code. > > So what can I do else? It's deprecated because it is confusing, but it is actually very useful performance wise in some cases, since it does pooling. I will make sure this feature remains available in the future. -- x Rémy Maucherat Developer & Consultant JBoss Group (Europe) SàRL x - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Single Thread is deprecated?
Hello out there, I want to build a servelt which access a database. To avoid race-conditions and to realize synchronous access, I decited to make a "Singe Thread" Servlet. But Eclipse told me that this is no longer a usable code. So what can I do else? Thank you... Gruss Christian - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
