aspose file tools*
The moose likes Servlets and the fly likes Are JSPs Thread Safe ? Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Java » Servlets
Bookmark "Are JSPs Thread Safe ?" Watch "Are JSPs Thread Safe ?" New topic
Author

Are JSPs Thread Safe ?

Gaurav Chikara
Ranch Hand

Joined: Jun 09, 2000
Posts: 410

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


SCJP,SCWCD,SCBCD<br />If Opportunity doesn't knock then build the door
Brett Knapik
Ranch Hand

Joined: Oct 15, 2000
Posts: 255
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
I am using the bean with request scope still i have to make each method of bean as synchronized?
Peter den Haan
author
Ranch Hand

Joined: Apr 20, 2000
Posts: 3252
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
This means that i have to make each method of my bean which has request scope as synchronized am i right?
Randall Twede
Ranch Hand

Joined: Oct 21, 2000
Posts: 4347
    
    2

Judging from what the others said, I think you will have to syncronize any method that accesses the XML document.
------------------
Dont blindly believe everything I say.


SCJP
Visit my download page
Gaurav Chikara
Ranch Hand

Joined: Jun 09, 2000
Posts: 410
Hi Randal
Any way to be on the safer side i have synchronised all my bean methods as no one else except u gave any views on it
any way thankx
Bhupinder Dhillon
Ranch Hand

Joined: Oct 12, 2000
Posts: 124
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
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
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
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???
shivani anand
Ranch Hand

Joined: Dec 28, 2000
Posts: 155
I think you can make your JSPs thread-safe by having them implement the SingleThreadModel interface.
shivani
Gaurav Chikara
Ranch Hand

Joined: Jun 09, 2000
Posts: 410
Hi Shivani
Here discussion was how to make the operation on xml as thread safe and not how to make a bean thread safe
any way good try
Randall Twede
Ranch Hand

Joined: Oct 21, 2000
Posts: 4347
    
    2

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
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
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
Originally posted by Gaurav Chikara:
but in JSP how can we write that our JSP implements singleThreadModel

<%@page isThreadSafe="false" %>
- Peter

Randall Twede
Ranch Hand

Joined: Oct 21, 2000
Posts: 4347
    
    2

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
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
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
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
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
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
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
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?

 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: Are JSPs Thread Safe ?