Monday, April 23, 2007

SingleThreadModel (Controlling Concurrent Access to Shared Resources)

Controlling Concurrent Access to Shared Resources

In a multithreaded server, it is possible for shared resources to be accessed concurrently. Besides scope object attributes, shared resources include in-memory data such as instance or class variables, and external objects such as files, database connections, and network connections. Concurrent access can arise in several situations:

* Multiple Web components accessing objects stored in the Web context
* Multiple Web components accessing objects stored in a session
* Multiple threads within a Web component accessing instance variables. A Web container will typically create a thread to handle each request. If you want to ensure that a servlet instance handles only one request at a time, a servlet can implement the SingleThreadModel interface. If a servlet implements this interface, you are guaranteed that no two threads will execute concurrently in the servlet's service method. A Web container can implement this guarantee by synchronizing access to a single instance of the servlet, or by maintaining a pool of Web component instances and dispatching each new request to a free instance. This interface does not prevent synchronization problems that result from Web components accessing shared resources such as static class variables or external objects.

Source>>http://java.sun.com/j2ee/tutorial/1_3-fcs/doc/Servlets5.html#73895

Nice interview

A Bad day in Java Land
At 8:24 AM on Apr 2, 2007, Akshay wrote:


It's interview season here and I happened to have one a while ago.
Bad experience- partly because I was not sure, partly because (I believe) the interviewer didn't know what he was talking. (he did sound sure though)

So let me outline what transpired.

He begand by reading out parts of my profile asked me a couple of personal questions and bang
# what's the difference between tomcat, weblogic and websphere?
easy question- back I replied.
a murmer of approval

# are servlets thread-safe?
i said no, a servlet instance is not inherently thread-safe; but the meaning of thread-safety depends on the scenario.
(what I had in mind here was, yes there might be concurrent access problems with servlet instances but not if they did not have instance variables)

so he asked me
# how can we make them thread safe?
i replied you could implement the SingleThreadModel interface but that would not solve concurrency problems.

and he again asked me the same question thinking i did not know the meaning of thread-safety. so i told him that I knew the meaning of thread-safety, but as I said it was a bit contextual.

murmers of disapproval
he asks me
# is jsp thread safe?
this time, im smarter, I say- no they're not thread safe by default.
he asks no?
i say no.
how sure are you?
100%
he asks why not
I tell him every jsp is going to be translated into a servlet and a servlet is not thread safe by default unless you implement the SingleThreadModel.
and he asks me how do I implement the SingleThreadModel?
so I say you just need to set the isThreadSafe attribute of the page directive to true.

So he asks me, will doing so, make the generated servlet class implement SingleThreadModel?
so I say yes.
And he asks, if you don't have that attribute, it will not implement that interface?
I say no.
(I'm getting irritated now, how many times do i need to say it)
So he says lets revisit the question again.
Is a jsp thread safe.
I say no, the isThreadSafe attribute has a default value of false.

now he asks me
# suppose there are ten concurrent requests to a s1 that implements SingleThreadModel and s2 tht doesnt', how many threads and processes are going to be created in each scenario?
(now I really don't understand this thing about processes, so I tell him about my understanding) I say- in either case, assuming there is only one instance of each servlet, the container creates one thread for each request irrespective of what kind of servlet instance it is. So in either case, there are only 10 threads, only the way they're scheduled to execute will differ. Because in the singlethreaded case, the execution of one thread would block the other threads and they would execute only one after the other.
and then he asks me a strange question (atleast it sounded strange to me)
he asked
# wot about the servlet? is that a seperate thread or a process? (And I thought WTH)
I told him it was neither, it's an object :-"
(Please let me know if I missed something here)

I show a little irritation
and he switches to JDBC this time.
and I don't know where he got this fancy for classloaders
he starts shooting-
# How do you register a driver?
I say when you do a Class.forName(), it loads the class and registers the driver class.
I said you could alternatively use the registerDriver method too...
he says ok (after a long time)
and then he asks
# what happens when you do Class.forName("java.lang.String")
I say, it loads the String class.
# are you sure?
Yes

# Why does a driver get registered when I do a Class.forName() and not a String?
(now, I'm not too sure, but I take a calculated guess)
I say its not just loading that occurs, the class also gets linked and initialized, and in the initialization process, the driver registers itself.


# what happens in the String case?
It probably sets up the pool, I'm not sure.

he goes on
# I have 4 Class.forName() calls each loading a different DB driver and then I call DriverManager.getConnection(). which of these drivers will it use?
I said the getConnection method takes a dbURL string. It resolves the driver to use from the protocol and subprotocol used in teh dbURL.

# How does it resolve?
(a snappy)I don't know.

and then he goes to ask me about problems with the Singleton design pattern. I say the instance is subject to concurrency problems.
so he asks how do you solve it.
I say you could make the getInstance method synchronized.

He asks are there problem with this approach?
i say- yes, it would be a bottleneck

How do you solve it?
(a tired) I don't know.

and then he goes on to ask me some simple questions on EJB's isIdentical method, and I easily mess it up and thats the end.

That was one tough nut to crack. Looking forward for your thoughts and opinions and most importantly ANSWERS.
:)

Source>> http://www.javalobby.org/java/forums/t92806.html