SCJP,SCWCD,SCBCD<br />If Opportunity doesn't knock then build the door
"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."
SCJP,SCWCD,SCBCD<br />If Opportunity doesn't knock then build the door
Originally posted by Brett Knapik:
If you use it as a session bean or session scope you should be OK.
Peter den Haan | peterdenhaan.com | quantum computing specialist, Objectivity Ltd
SCJP,SCWCD,SCBCD<br />If Opportunity doesn't knock then build the door
SCJP
Visit my download page
SCJP,SCWCD,SCBCD<br />If Opportunity doesn't knock then build the door
SCJP,SCWCD,SCBCD<br />If Opportunity doesn't knock then build the door
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
SCJP,SCWCD,SCBCD<br />If Opportunity doesn't knock then build the door
SCJP,SCWCD,SCBCD<br />If Opportunity doesn't knock then build the door
SCJP
Visit my download page
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)
Peter den Haan | peterdenhaan.com | quantum computing specialist, Objectivity Ltd
Originally posted by shivani anand:
I think you can make your JSPs thread-safe by having them implement the SingleThreadModel interface.
shivani
SCJP,SCWCD,SCBCD<br />If Opportunity doesn't knock then build the door
Originally posted by Gaurav Chikara:
but in JSP how can we write that our JSP implements singleThreadModel
Peter den Haan | peterdenhaan.com | quantum computing specialist, Objectivity Ltd
SCJP
Visit my download page
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.
SCJP,SCWCD,SCBCD<br />If Opportunity doesn't knock then build the door
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.
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?
Peter den Haan | peterdenhaan.com | quantum computing specialist, Objectivity Ltd
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]
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.
SCJP,SCWCD,SCBCD<br />If Opportunity doesn't knock then build the door
Peter den Haan | peterdenhaan.com | quantum computing specialist, Objectivity Ltd
Originally posted by Gaurav Chikara:
hey am i wrong?
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?
SCJP,SCWCD,SCBCD<br />If Opportunity doesn't knock then build the door
Be reasonable. You can't destroy everything. Where would you sit? How would you read a tiny ad?
a bit of art, as a gift, that will fit in a stocking
https://gardener-gift.com
|