Are JSPs Thread Safe ?

I want to know are JSP'S also thread safe In other words do the beans invoked in a JSP Page are also Thread Safe I m invoking a Bean which will update some value of an XML Document.Do i have to write each method of Bean as synchronized or Container will take care of it implicitly Pls suggest something

If you use it as a session bean or session scope you should be OK. ------------------ In Gates we trust. Yeah right....

"Programming today is a race between software engineers striving to build bigger and better idiot-proof programs, and the Universe trying to produce bigger and better idiots. So far, the Universe is winning."

Gaurav Chikara
Ranch Hand

Joined: Jun 09, 2000
Posts: 410

posted Mar 07, 2001 14:05:00

0

I am using the bean with request scope still i have to make each method of bean as synchronized?

Originally posted by Brett Knapik:If you use it as a session bean or session scope you should be OK.

Multiple servlets executing request threads may have active access to a single session object at the same time. The Developer has the responsibility to synchronize access to resources stored in the session as appropriate. -- v2.2 servlet spec, section 7.7.1. You're probably getting visions of users furiously clicking Refresh in an attempt to break your website, and think that this is mere theory. It isn't. If your website has frames, it is quite common for browsers to open multiple connections with your server and request all frames simultaneously. All these connections live in the same session, and multiple threads will be accessing the same session state. So yes, if you want a truly robust application you will have to make your session-scoped objects threadsafe. - Peter

[This message has been edited by Peter den Haan (edited March 07, 2001).]

Gaurav Chikara
Ranch Hand

Joined: Jun 09, 2000
Posts: 410

posted Mar 07, 2001 14:54:00

0

This means that i have to make each method of my bean which has request scope as synchronized am i right?

If you are using request scope then you don't need to synchronize anything except the XML document.

Gaurav Chikara
Ranch Hand

Joined: Jun 09, 2000
Posts: 410

posted Mar 07, 2001 17:42:00

0

Hi Bhupinder XML Document has nothing to do with synchronisation we r accessing it with beans only so beans have to be dealt with synchronisation i think u misinterpreted it

Bhupinder Dhillon
Ranch Hand

Joined: Oct 12, 2000
Posts: 124

posted Mar 08, 2001 09:28:00

0

Originally posted by Gaurav Chikara:Hi Bhupinder XML Document has nothing to do with synchronisation we r accessing it with beans only so beans have to be dealt with synchronisation i think u misinterpreted it

What I meant was.. declare the document as a static member and get a lock on that anywhere you access it. Thus, you don't have to synchronize the bean methods themselves. And also, make sure you are using one classloader. Getting a lock on the bean instance won't do you any good, because a new instance is created everytime a request comes in.

Gaurav Chikara
Ranch Hand

Joined: Jun 09, 2000
Posts: 410

posted Mar 08, 2001 10:23:00

0

Hi Bhupinder I think there is some confusion I m creating XML document through my servlet and servlets are thread safe then there is no pint declaring xmldocument as static as xmldocument is not a static class and about classloader ya i m using only default classloader I think i cleared the confusion? Now also u have to say that declare xmldocument as static member???

I think, but I'm not certain, that I dodged the bullet by using servlets that implement SingleThreadModel to access my database(a shared resource like your XML) Any comments? Am I wrong? Is there possibility of conflict? I am actually quite unsure that my site will work properly with many requests. With SingleThreadModel, there are as many instances of the servlet as there are clients using it. Maybe my database is not threadsafe. [This message has been edited by Randall Twede (edited March 09, 2001).]

Peter den Haan
author
Ranch Hand

Joined: Apr 20, 2000
Posts: 3252

posted Mar 09, 2001 01:56:00

0

Originally posted by Randall Twede:I think, but I'm not certain, that I dodged the bullet by using servlets that implement SingleThreadModel to access my database(a shared resource like your XML)

By implementing SingleThreadModel you can get away with thread-unsafe servlets. Beware though that any session scoped objects probably still need to be threadsafe. Also, take into account that servlet instances may live for a very long time. If you open a database connection in init() then the database may eventually expire it. (If you open it when servicing a request, your servlet is probably threadsafe in the first place). - Peter

Gaurav Chikara
Ranch Hand

Joined: Jun 09, 2000
Posts: 410

posted Mar 09, 2001 11:38:00

0

Originally posted by shivani anand: I think you can make your JSPs thread-safe by having them implement the SingleThreadModel interface. shivani

In servlet we write that class implements SingleThreadModel but in JSP how can we write that our JSP implements singleThreadModel do we have to goto temp directory where it creates java file of our JSP page and make the required change there?? any comments?

Peter den Haan
author
Ranch Hand

Joined: Apr 20, 2000
Posts: 3252

posted Mar 09, 2001 13:23:00

0

Originally posted by Gaurav Chikara:but in JSP how can we write that our JSP implements singleThreadModel

Peter, I open the connection with each request. Not only that but I am not using a connection pool, I create a new connection for each request. It is not too slow in IE but is slower than I like in Netscape. I believe I should use a connection pool. It just seemed harder to implement(my first time). Using a connection pool, it will still be threadsafe as long as I open then close the connection for each request? My servlets also update some text files which can also be read, but it is not important if 2 clients have different versions. Is it ok to not worry about that? I'm still sort of confused about threadsafe issue. I should read more about it.

Gaurav Chikara
Ranch Hand

Joined: Jun 09, 2000
Posts: 410

posted Mar 09, 2001 17:43:00

0

Hi U r using write technique using connection pool regarding netscape browser issue It is a very dull browser which consumes a lot of resources and takes time to load pluggins etc and thus gives slow throughput Connection pooling is done to ensure thread safety only hope it helps

Originally posted by Randall Twede:Peter, I open the connection with each request. Not only that but I am not using a connection pool, I create a new connection for each request. It is not too slow in IE but is slower than I like in Netscape. I believe I should use a connection pool. It just seemed harder to implement(my first time). Using a connection pool, it will still be threadsafe as long as I open then close the connection for each request? My servlets also update some text files which can also be read, but it is not important if 2 clients have different versions. Is it ok to not worry about that? I'm still sort of confused about threadsafe issue. I should read more about it.

Peter den Haan
author
Ranch Hand

Joined: Apr 20, 2000
Posts: 3252

posted Mar 10, 2001 02:39:00

0

Originally posted by Randall Twede:I open the connection with each request. Not only that but I am not using a connection pool, I create a new connection for each request. It is not too slow in IE but is slower than I like in Netscape.

The connection is not likely to be the cause of the Netscape slowness. Still, in a serious web application it's a bad idea, as the opening and closing of connections will seriously affect the scalability of your servlets. The database is likely to respond slower as the number of simultaneous connections grows, the servlet engine will need many more threads because each request takes 250ms to service instead of 25ms, etc.

I believe I should use a connection pool. It just seemed harder to implement(my first time). Using a connection pool, it will still be threadsafe as long as I open then close the connection for each request?

A connection pool is only harder if you insist on coding your own (a useful exercise, but difficult to get right). A good connection pool will be threadsafe, will ensure that the connection you get is in good working order, cleaning up connections that no longer work. With a connection pool you no longer open and close connections yourself, instead you borrow an open connection from the pool and give it back when you're finished. Most application servers ship with a connection pool. If yours doesn't, or if you don't want to tie yourself to a specific server, look here.

My servlets also update some text files which can also be read, but it is not important if 2 clients have different versions. Is it ok to not worry about that?

Well, you have plenty to worry about. Just reading would be fine, but updating introduces all kinds of threading issues. Two simultaneous requests which try to update this file simultaneously will probably make a big mess. Ditto if an attempt is made to read the file while it is being updated. Even if you would update a copy of the file and then move the updated copy in the place of the file, there probably still is a tiny "window" during the move when the file cannot safely be read. I don't think Java gives you access to the host OS's file locking features. If you are absolutely sure that your application will not be used in a clustered environment, you could protect all your file-access code by putting it inside a synchronized block. It should synchronize on an application-wide, Singleton object (i.e. for each file there should only ever be one copy of the object being synchronized on). This could be an application-scoped object, or a servlet which does not implement SingleThreadModel, or a classic Singleton class -- but beware when modifying your classes because if the server loads a new class version your Singleton may no longer be a singleton! A single application-scoped object that handles all access to the file(s) might be a good way to go about it. This object would have to be threadsafe, obviously. - Peter

[This message has been edited by Peter den Haan (edited March 10, 2001).]

Bhupinder Dhillon
Ranch Hand

Joined: Oct 12, 2000
Posts: 124

posted Mar 12, 2001 12:26:00

0

Originally posted by Peter den Haan: Well, you have plenty to worry about. Just reading would be fine, but updating introduces all kinds of threading issues. Two simultaneous requests which try to update this file simultaneously will probably make a big mess. Ditto if an attempt is made to read the file while it is being updated. Even if you would update a copy of the file and then move the updated copy in the place of the file, there probably still is a tiny "window" during the move when the file cannot safely be read. I don't think Java gives you access to the host OS's file locking features. If you are absolutely sure that your application will not be used in a clustered environment, you could protect all your file-access code by putting it inside a synchronized block. It should synchronize on an application-wide, Singleton object (i.e. for each file there should only ever be one copy of the object being synchronized on). This could be an application-scoped object, or a servlet which does not implement SingleThreadModel, or a classic Singleton class -- but beware when modifying your classes because if the server loads a new class version your Singleton may no longer be a singleton! A single application-scoped object that handles all access to the file(s) might be a good way to go about it. This object would have to be threadsafe, obviously. - Peter

[This message has been edited by Peter den Haan (edited March 10, 2001).][/B]

Now that's what I was trying to tell Gaurav, eh! Doesn't matter how many synchronized methods you have in your bean, as long as you don't synchronize the file itself.. it ain't gonna do you any good.

Gaurav Chikara
Ranch Hand

Joined: Jun 09, 2000
Posts: 410

posted Mar 12, 2001 14:07:00

0

As per said by Peter "you could protect all your file-access code by putting it inside a synchronized block. " and beans are having the file acess code i mean the class in which i m parsing the xml to update it retrives the parameters from getter methods which i have synchronized so i think that at a time only one set of parameters will be retrieved from these synchornized methods and my xml is thread safe hey am i wrong?

Originally posted by Bhupinder Dhillon: Now that's what I was trying to tell Gaurav, eh! Doesn't matter how many synchronized methods you have in your bean, as long as you don't synchronize the file itself.. it ain't gonna do you any good.

Peter den Haan
author
Ranch Hand

Joined: Apr 20, 2000
Posts: 3252

posted Mar 12, 2001 15:04:00

0

Just beware that your code will have to be synchronized at the right level. The fact that getters and setters are nicely synchronized merely guarantees that threading issues won't mess up your object internally. But your servlets accessing it may still (implicitly) assume that the XML document doesn't change between method calls. As soon as you release your lock on an object (i.e. leave the synchronize block), anything may happen to it. Always remember that when dealing with threading issues. - Peter

Bhupinder Dhillon
Ranch Hand

Joined: Oct 12, 2000
Posts: 124

posted Mar 12, 2001 16:40:00

0

Originally posted by Gaurav Chikara:hey am i wrong?

Why don't you just post the relevant bean code? That way we can give you a definitive answer instead of making educated guesses of what you have done and whether it's thread safe or not?

Gaurav Chikara
Ranch Hand

Joined: Jun 09, 2000
Posts: 410

posted Mar 12, 2001 18:51:00

0

Bean is vey lengthy but i tell u all methods of it including the method in which i m parsing the xmldocument to get the requested node value is also synchronized I think that now my bean is Thread safe

Originally posted by Bhupinder Dhillon: Why don't you just post the relevant bean code? That way we can give you a definitive answer instead of making educated guesses of what you have done and whether it's thread safe or not?