This week's giveaway is in the Threads forum.
We're giving away four copies of Java Concurrency Live Lessons and have Doug Schmidt on-line!
See this thread for details.
Win a copy of Java Concurrency Live Lessons this week in the Threads forum!
  • Post Reply Bookmark Topic Watch Topic
  • New Topic

JSP is thread safe  RSS feed

 
sandy sean
Ranch Hand
Posts: 69
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
JSP is thread safe by default but What is the meaning when we say


a JSP is thread-safe?
 
Tim Holloway
Bartender
Posts: 18531
61
Android Eclipse IDE Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
No it isn't.
 
Paul Clapham
Sheriff
Posts: 22185
38
Eclipse IDE Firefox Browser MySQL Database
  • Likes 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
A JSP is compiled into Java code. So saying that a JSP is thread-safe (which, as Tim says, may or may not be true) is the same as saying that the compiled Java class is thread-safe.

However in real life a JSP should only be generating HTML to be sent to the browser. It should never be updating the state of any objects in the application, and that's the only time when thread safety is an issue. So for properly-written JSPs, thread safety is irrelevant.
 
Tim Holloway
Bartender
Posts: 18531
61
Android Eclipse IDE Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Paul Clapham wrote:. It should never be updating the state of any objects in the application, and that's the only time when thread safety is an issue. So for properly-written JSPs, thread safety is irrelevant.


Technically, not so. It's true that read-only access means that thread safety is less of an issue, but if you are accessing volatile objects/properties in a JSP and you don't synchronize the access, then there is the potential for a corrupt display.

Which, in turn could propagate back to the server if the corrupted display properties are part of a form that gets submitted.

It's rarely an issue for basic webapps, where the request is supposed to be turned around as fast as possible anyway, but I've actually had people break stuff of mine by slipping through cracks that were only milliseconds in width, so if it's critical, enforce thread safety even on read-only requests.
 
Jayesh A Lalwani
Rancher
Posts: 2762
32
Eclipse IDE Spring Tomcat Server
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I might be mistaken, but I always thought that any variables in the jsp would be local scoped. Is that wrong?
 
Bear Bibeault
Author and ninkuma
Marshal
Posts: 65833
134
IntelliJ IDE Java jQuery Mac Mac OS X
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I'll disagree with Tim somewhat. The notion of using stale data isn't a thread-safety issue. The same thing can happen if anyone brings up a form loaded with current data, goes to lunch, and then submits the form, over-writing changes that someone else made while they were chowing down on chicken fingers. It's a real problem, but it's not a thread-safety issue.

Like a Java class, a JSP isn't inherently thread-safe or not thread-safe, it's what one does in the JSP that makes it thread-safe or not.
 
Bear Bibeault
Author and ninkuma
Marshal
Posts: 65833
134
IntelliJ IDE Java jQuery Mac Mac OS X
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Jayesh A Lalwani wrote:I might be mistaken, but I always thought that any variables in the jsp would be local scoped. Is that wrong?


Yes, it's wrong.

How many times have we seen this in a JSP:

<!% int counter = 0; %>

It's also possible, even without scriptlets, to have read/write effects on scoped variables in session and application scope.
 
Tim Holloway
Bartender
Posts: 18531
61
Android Eclipse IDE Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Bear Bibeault wrote:I'll disagree with Tim somewhat. The notion of using stale data isn't a thread-safety issue. The same thing can happen if anyone brings up a form loaded with current data, goes to lunch, and then submits the form, over-writing changes that someone else made while they were chowing down on chicken fingers. It's a real problem, but it's not a thread-safety issue.

Like a Java class, a JSP isn't inherently thread-safe or not thread-safe, it's what one does in the JSP that makes it thread-safe or not.


Stale data isn't the same thing as unsynchronized data. It's possible to pull data that is out of date but agrees with itself even in a thread-safe operation, and that has its own risks, because you can effectively back out an update.

However, what I was referring to was the case where some other thread is actively modifying the data being used in the display-only JSP while the display-only JSP is in the act of fetching it for display.

In such cases, you can see items for example, where a column of data items is being added up and result in a final page that displays 1+1=3. Stale data might be adding A and B and get 1+1=2 when B has already been incremented, but at least the total will be a valid total. With unsynchronized data, you might fetch A =1, B=1, and A+B=3 because B was set to 2 while the the page was being rendered, after the display value of B had been fetched for display (assuming that the total was also being fetched and not added on the spot). This may seem like a rather contrived example, but variations on this sort of thing are why weird things can happen if you're not careful.
 
Bear Bibeault
Author and ninkuma
Marshal
Posts: 65833
134
IntelliJ IDE Java jQuery Mac Mac OS X
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
But I would still argue that that is not a thread-safety issue. Any resource can fetch data that changes right after it is fetched. If we take the case where a controller fetches data from the DB and sends it to a JSP for display, if the data gets changed in the DB nanoseconds after it is fetched, the data on the JSP is stale, but it's not a thread-safety issue. Even if the data is in memory and changed by another thread, it's not a thread-safety issue.

Unless the JSP tries to write to a shared resource, there is no thread-safety issue. There's certainly the possibility of stale data. But that's not a threading problem.
 
Tim Holloway
Bartender
Posts: 18531
61
Android Eclipse IDE Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
To the contrary. That is the very definition of thread safety.

For a block of code (or more accurately, a set of data) to be thread-safe, no other thread - or, for that matter, I/O device, interrupt service, etc. must be able to modify the data being referenced and/or altered by a thread. Whether the other thread is a simple thread, a thread on another core in the same multi-core CPU, or even another machine on another continent.

Java provides thread-safe access to memory objects within a JVM using the "synchronized" facility. When a thread obtains synchronization on an object, any other thread attempting to synchronize on that object will be put to sleep until the first thread exits synchronization. And so on, in a First-In/First-Out (FIFO) order. This is enforced by the JVM, which in turn may use various mechanisms to force the locking mechanisms to even lower levels. Most modern CPUs have special instructions for that purpose, in fact. Not to mention a lot of special microcode in order to avoid issues where hardware caches and/or bus controllers (both memory and I/O) get in the way.

At a higher level, database data synchronization is likewise maintained via database transaction control (if used). That's the database version of Java's synchronization, and it ensures the consistency part of ACID in database operations. However, transactions and thread safety are not directly inter-related unless the developer takes proper care. Otherwise you can end up with multiple memory objects generated from the same database record in various degrees of staleness.

 
Tim Holloway
Bartender
Posts: 18531
61
Android Eclipse IDE Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Incidentally, the C programming language provides a keyword that defines data as the exact opposite of thread-safe: "volatile".

This feature was necessary because C compilers often fetch data into hardware registers and, for efficiency purposes, assume that the memory from which the data was fetched remains unchanged for the life of the operation in question. In a number of cases, such as I/O status ports, that isn't true or even desirable (for example, when you are polling for a "ready" status bit). Declaring the item in question as volatile causes the value to be re-fetched on every read reference, even if a cached register copy would have been faster.
 
Bear Bibeault
Author and ninkuma
Marshal
Posts: 65833
134
IntelliJ IDE Java jQuery Mac Mac OS X
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I'll still disagree. For the database example, there is no way to guarantee that the database cannot be changed between the time that the info is fetched, and that it is displayed. What's changing the data is rather irrelevant.

We'll just have to disagree on the definition of thread safety and whether it covers the stale data situation or not.
 
Tim Holloway
Bartender
Posts: 18531
61
Android Eclipse IDE Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I understand your objection, but in Sun/Oracle terms "thread safe" has a very specific meaning relating to thread access control of objects within the memory of the JVM. What you are concerned with (and rightly so) is more what I might call "functionally safe"

Database objects are located external to the JVM, and as result, are not subject to the thread safety mechanisms of the JVM. Which is why they have their own separate transaction systems to ensure linear access to the data objects contained within the database itself.

But Java cannot directly access those objects. It can only request copies of the database objects that it then stores as Java objects within the JVM. Since there's no direct linkage between these copies and their originals, it's perfectly possible for a JVM to contains multiple copies of the database objects, have them go stale and/or be independently modified. But what thread safety means within the context of a servlet or JVM is that specific instances of those objects have been protected against concurrent modifications of those specific instances.

And unless synchronization locks have been set against those instances explicitly by the JSP/servlet code or class definitions, those instances are not thread-safe.

Truly "safe" access to things like database objects isn't just something that has to be done at the thread level. It also has to be done at the database level. And possibly beyond, since in some systems, it's not sufficient to protect data merely during the duration of a thread processing a single HTTP request/response cycle, but over several cycles, involving the progress of a transaction. In this case, the ACID requirements would demand that the database objects be safe for the duration of the database function, even though more than one thread would be involved.

So, just to summarize, here are some levels of access control for an item of data:

1. JVM level. Protection of specific object/property instances. Via "synchronized" facility.
2. Simple database transaction within a request/reponse cycle. Protects the database objects. Via database transaction control within a thread.
3. Workflow transaction comprising several request/response cycles. Basically, you lock a record, run through a set of screens to do things with it, then commit or rollback your work. Via database transaction control spanning threads.
4, Composite transaction. As an example, fetching records from 2 different databases (perhaps Oracle and SQL server), doing things to both records and committing changes to both databases as an ACID operation. Also known as Extended Transactions.
 
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!