Newbie: is JSP thread safe?

New to JSP and trying to understand the thread-safe-code thing.
An example maybe is the best way to ask (Tomcat 4 and Win2000/IIS, MsSQL2000, MsJDBC)
I have a mypage.jsp page which uses a bean (mybean.class) to fill up the page from a database and also make updates to the database. So the bean has connect,disconnect,query by returning resultsets, all the database stuff.
The question: suppose two users get to the page at the same time and press the update button at the same time, what happens?
user1 -> mypage.jsp -> mybean.class
user2 -> mypage.jsp -> mybean.class
So does the mypage.jsp or mybean.class run in tomcat for both users as one copy? Can user1 database update mix up with user2 database update? And if yes, how can i prevent that? Or am I totally lost..
-- Mixed up newbie --

Hi,
What we are talking about here is Transaction not Threading.
To separate view with business and data access, it's the business class model that take care about it and not the view (JSP pages).
So here's what to do in a serious world :
JSP --> class that support JTA (it may be a simple class or an EJB) --> DAO class.
Hope it's clear enough

Similar Messages

Thread safe bean

My business logic bean is being accessed via jsp's
It looks something like this
public class MyBean
private int myInt;
private String MySting;
* Bean sets and gets
public void setMyInt(int i)
myInt = i;
public void setMyString (String s)
myString = s;
public int getMyInt()
return myInt;
public String getMyString()
return myString;
* Public wrapper for private business logic
public void doSomethingWrapper()
myString = doSomething(getMyInt())
* Private business logic
private String doSomething(int i)
// business Logic
return a_string;
Now, I've been told that this is not thread safe and that will not work. My big concern is
with making the Bean properties thread safe, anyone way any suggestions? Thanks in advance.

Based on your requirement, i see a necessicity for session scoping the bean.
And yes in servlet/jsp multiple thread can act on single instance of a bean.
So what you do is add synchronized keyword for the getter and setter method. For example if have modify your example given above, it would look something like this
public class MyBean
private int myInt;
private String MySting;
* Bean sets and gets
public synchronized void setMyInt(int i)
   myInt = i;
public synchronized void setMyString (String s)
   myString = s;
public synchronized int getMyInt()
   return myInt;
public synchronized String getMyString()
   return myString;
* Public wrapper for private business logic
* You dont necessarily have to synchronze this method because
* getMyInt() is anyway synchronized.
public void doSomethingWrapper()
   myString = doSomething(getMyInt())
* Private business logic
* If you dont access any properties(member variables) dont synchronize, if you do then yes
private String doSomething(int i)
   // business Logic
   return a_string;
}By adding synchronized keyword the java virtual machine ensures method level serial execution, so no corruption problem.
But you require more than method level synchronization, then you need some other mechanism like semaphore and just.
In most of the case, former would be just enough but if your case is not so then let me know, I can suggest other mechanism which suit your needs

Using IPortalComponentProfile: Thread safe variables?

Hi guys!
Im trying to understand (deeply) the framework used by the EP and I found something that disturb me like crazy the use of the IPortalComponentProfile.
I just dont get it The profile suppose to hold variables for your iView instance right? Now, if you are trying to have thread safe variables in your iView (which is desirable) why you have to used the application scope (in a JSP page) to retrieve those variables??? As you know, the application object in a JSP page refers to the ServletContext: All those variables are visible to the entire application which is completely the opposite to the thread safe concept Am I wrong? Did I miss something?
If you guys have the clue about this please let me know
Thanks in advance!
Bye.
Al

Here's the answer taking from the Portal docs:
"Except the scope option APPLICATION all the other scope options follow the JSP specifications from Sun Microsystems. <b>The option APPLICATION had to be modified to meet the requirements for a portal.</b> The standard recommendation of APPLICATION would allow access to a the bean through out the whole portal (it would be located in the "Web Application" shell if you look at the following overview chart). In the portal the sphere for APPLICATION is defined as the portal component. This gives the portal component control over the bean but the bean cannot be accessed by other users or other applications of the same user."
Al.

Is JSF Page thread safe

Hi ,
I was wondering if JSF page is thread safe
Okay here is my scenarion.
1. in order to prevent some of the value get re instatiate when the page rendered i declared some of them as static.
However i make some checking if the Page is accessed for the first time , it will set this static object back to Null , if it is a postback it will hold current value which i assign.
The question is ,
1. i have two or three user performing concurrent request will it be a problem ????
2. i notice when i destroy / invalidate the SessionBean. ( user logout scenario ) .
When the user login again , why the static variable still holding the same value . i thought the page should be destroyed?? ( Thats why i check if the page is accessed for the first time , i will set all my object to null ).
Thanks.

The JSP will we translated to a servet by the application server, and therefore will run as a servlet. Servlets are not thread safe, you'll have to elaborate synchronized code blocks to allow one thread in the critical code, wich in turn has it's drawbacks.
Best regards
Antonio.

Are HttpSessions thread-safe?

When multiple users submit a request on the same servlet, they will each access a different HttpSession, which is thread-safe.
However, it seems possible that a single user can issue multiple requests at around the same time (ie. multiple browser windows or simply clicking the same link twice) for which the browser would provide the same session tracking info (cookie etc.). In this case, is it possible that the two requests would be handled in two separate threads, but access the same HttpSession simultaneously?
If this is possible, what are common methods for protecting against it?
(eg. synchronize on the session object per page?)

Normally the container assigns each received request to a thread and executes it. If two requests are sent by a browser, then it is up to the browser to disregard the response to the first request (using sequence numbers). I have examined the Servlet 2.3 specification and can't find any mention that the servlet container is required to detect several requests for the same page from the same client while the earlier request(s) are still executing, and to terminate the earlier request(s) first! Of course this is an area where different brands of servlet container could behave differently, but to terminate a thread's execution without warning seems questionable (not to mention non-compliant with the standards). The discussion you refer to seems a little strange, and it didn't really conclude on solid ground...
The JSP test page I used is as follows.
<%@ page contentType="text/html; charset=iso-8859-1" language="java" %>
<%@ page info="TEST" %>
<%! static int x = 0; %>
<%-- synchronized (session) { --%>
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd">
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
<title>TEST</title>
</head>
<body>
<%
String x1 = (String) session.getAttribute("x");
if (x1 == null)
x1 = "" + x++;
else
x1 += "(" + x++ + ")";
session.setAttribute("x", x1);
%>
Initial value is "<%= x1 %>".
<br>
<%
Thread.currentThread().sleep(10000); // Make it easier to reproduce the race condition
String x2 = (String) session.getAttribute("x");
x2 += "[" + x++ + "]";
session.setAttribute("x", x2);
%>
Final value is "<%= x2 %>".
</body>
</html>
<%-- } --%> // synchronized (session)
When I submit the first request and resend the request a couple of seconds later, the browser (NS7/IE6) shows only the result of the second request, and takes about 10 seconds (the two requests are executing concurrently).
Initial value is "(0)(1)".
Final value is "(0)(1)[2][3]".
When I do the same thing with the synchronization enabled, I get the following result, and it take around 20 seconds for the second page to arrive (since the two requests are serialised by the servlet).
Initial value is "(0)[1](2)".
Final value is "(0)[1](2)[3]".
/Cheers, Ross.

Question about EJB and thread safe coding - asking again!

sorry everyone, no one seems to be interested in helping me on this, so i post it again.
i have a question about the EJB and thread safe coding. when we build EJBs, do we need to worry about thread safe issue? i know that EJBs are single threaded, and the container manages the thread for us. maybe i am wrong about this. if i wasnot, how can we program the EJB so that two or more instance of EJB are not going to have deadlock problem when accessing data resources. do we need to put syncronization in ours beans, do we even need to worry about creating a thread safe EJB? thanks in advance. the question really bothers me a lot lately.

sorry everyone, no one seems to be interested in
helping me on this, so i post it again.Excellent plan. Why not search a little bit on your own instead of waiting for your personal forum slaves to answer your call. See below.
i have a question about the EJB and thread safe
coding. when we build EJBs, do we need to worry about
thread safe issue? Read this: http://forum.java.sun.com/thread.jsp?forum=13&thread=562598&tstart=75&trange=15
i know that EJBs are single
threaded, and the container manages the thread for us.
maybe i am wrong about this. if i wasnot, how can we
program the EJB so that two or more instance of EJB
are not going to have deadlock problem when accessing
data resources. do we need to put syncronization in
ours beans, do we even need to worry about creating a
thread safe EJB? thanks in advance. the question
really bothers me a lot lately.
Java's Thread Tutorial
JavaWorld: Introduction to Java threads
IBM: Introduction to Java threads
Google: java+threads+tutorial

How to make thread safe?

Hi guys,
I got a backing bean like
public class UserBean{
private String firstname;
     public String getFirstname() {
          return firstname;
     public void setFirstname(String firstname) {
          this.firstname = firstname;
the firstname variable is also use in the jsp page like
<h:outputText value="#{userBean.firstname}"/>
If the "setFirstname" method is executed by two threads, then it's likely that the value of the firstnameinstance variable will be replaced by the second thread while the first thread is still using it. So does JSF handle this thread safe condition? Please advice, Thanks !
regards,
kmthien

If the bean is scoped in the request, according to the servlet spec, only one thread should ever access it. If the bean in scoped in the session/application, then it's up to you to manage synchronization within your bean as with every other web framework.

Are immutable objects thread safe

I am having a debate with legosa as to if immutable objects are thread safe @
http://forum.java.sun.com/thread.jsp?forum=37&thread=525250
I would like the java gurus to put in their thoughts over here.

I am having a debate with legosa as to if immutable
objects are thread safe @
http://forum.java.sun.com/thread.jsp?forum=37&thread=52
250
I would like the java gurus to put in their thoughts
over here.There are some problems with the java memory model that can cause immutable objects to not be thread safe. This is discussed in the section Problem#1 in the following article from IBM:
http://www-106.ibm.com/developerworks/library/j-jtp02244.html
According to this article, some of the problems have been fixed in jdk1.4, while other fixes will have to wait until jdk1.5.

Is ServletContext::log() thread-safe?

I am running Websphere Application Server v6.0. Tried to search at http://publib.boulder.ibm.com/infocenter/wasinfo/v6r0/index.jsp (these are WAS6.0 docs) but found nothing useful. Also found a post where thread-safety is confirmed, but without any reasoning: http://forum.java.sun.com/thread.jspa?forumID=33&threadID=208948.

hi Antalas,
for Tomcat,it is not thread safe.but for WebSphere it is.for more info click on the following link :
http://www.webagesolutions.com/knowledgebase/waskb/waskb026/index.html.
[email protected]

SSRS - Is there a multi thread safe way of displaying information from a DataSet in a Report Header?

In order to dynamically display data in the Report Header based in the current record of the Dataset, we started using Shared Variables, we initially used ReportItems!SomeTextbox.Value, but we noticed that when SomeTextbox was not rendered in the body
(usually because a comment section grow to occupy most of the page if not more than one page), then the ReportItem printed a blank/null value.
So, a method was defined in the Code section of the report that would set the value to the shared variable:
public shared Params as String
public shared Function SetValues(Param as String ) as String
Params = Param
Return Params
End Function
Which would be called in the detail section of the tablix, then in the header a textbox would hold the following expression:
=Code.Params
This worked beautifully since, it now didn't mattered that the body section didn't had the SetValues call, the variable persited and the Header displayed the correct value. Our problem now is that when the report is being called in different threads with
different data, the variable being shared/static gets modified by all the reports being run at the same time.
So far I've tried several things:
- The variables need to be shared, otherwise the value set in the Body can't be seen by the header.
- Using Hashtables behaves exactly like the ReportItem option.
- Using a C# DLL with non static variables to take care of this, didn't work because apparently when the DLL is being called by the Body generates a different instance of the DLL than when it's called from the header.
So is there a way to deal with this issue in a multi thread safe way?
Thanks in advance!

Hi Angel,
Per my understanding that you want to dynamic display the group data in the report header, you have set page break based on the group, so when click to the next page, the report hearder will change according to the value in the group, when you are using
the shared variables you got the multiple thread safe problem, right?
I have tested on my local environment and can reproduce the issue, according to the multiple safe problem the better way is to use the harshtable behaves in the custom code, you have mentioned that you have tryied touse the harshtable but finally got
the same result as using the ReportItem!TextBox.Value, the problem can be cuased by the logic of the code that not works fine.
Please reference to the custom code below which works fine and can get all the expect value display on every page:
Shared ht As System.Collections.Hashtable = New System.Collections.Hashtable
Public Function SetGroupHeader( ByVal group As Object _
,ByRef groupName As String _
,ByRef userID As String) As String
Dim key As String = groupName & userID
If Not group Is Nothing Then
Dim g As String = CType(group, String)
If Not (ht.ContainsKey(key)) Then
' must be the first pass so set the current group to group
ht.Add(key, g)
Else
If Not (ht(key).Equals(g)) Then
ht(key) = g
End If
End If
End If
Return ht(key)
End Function
Using this exprssion in the textbox of the reportheader:
=Code.SetGroupHeader(ReportItems!Language.Value,"GroupName", User!UserID)
Links belowe about the hashtable and the mutiple threads safe problem for your reference:
http://stackoverflow.com/questions/2067537/ssrs-code-shared-variables-and-simultaneous-report-execution
http://sqlserverbiblog.wordpress.com/2011/10/10/using-custom-code-functions-in-reporting-services-reports/
If you still have any problem, please feel free to ask.
Regards
Vicky Liu

How can I use a Selector in a thread safe way?

Hello,
I'm using a server socket with a java.nio.channels.Selector contemporarily by 3 different threads (this number may change in the future).
From the javadoc: Selectors are themselves safe for use by multiple concurrent threads; their key sets, however, are not.
Following this advise, I wrote code in this way:
         List keys = new LinkedList(); //private key list for each thread
         while (true) {
          keys.clear();
          synchronized(selector) {
              int num = selector.select();
              if (num == 0)
               continue;
              Set selectedKeys = selector.selectedKeys();
              //I expected this code to produce disjoint key sets on each thread...
              keys.addAll(selectedKeys);
              selectedKeys.clear();
          Iterator it = keys.iterator();
          while (it.hasNext()) {
              SelectionKey key = (SelectionKey) it.next();
              if ((key.readyOps() & SelectionKey.OP_ACCEPT) == SelectionKey.OP_ACCEPT) {
               Socket s = serverSocket.accept();
               SocketChannel sc = s.getChannel();
               sc.configureBlocking( false );
               sc.register( selector, SelectionKey.OP_READ );
              } else if ((key.readyOps() & SelectionKey.OP_READ) == SelectionKey.OP_READ) {
//.....Unfortunately synchronizing on the selector didn't have the effect I expected. When another thread select()s, it sees the same key list as the other thread that select()ed previously. When control arrives to serverSocket.accept(), one thread goes ahead and the other two catch an IllegalBlockingModeException.
I'm not willing to handle this exception, the right thing to do is giving disjoint key sets to each thread. How can I achieve this goal?
Thanks in advance

A single thread won't be enough cause after reading data from the socket I do some processing on it that may take long.So despatch that processing to a separate thread.
Most of this processing is I/O boundI/O bound on the socket? or something else? If it's I/O bound on the socket that's even more of a reason to use a single thread.
Anyway I think I'll use a single thread with the selector, put incoming data in a queue and let other 2 or 3 threads read from it.Precisely. Ditto outbound data.
Thanks for your replies. But I'm still curious: why is a selector thread safe if it can't be used with multiple threads because of it's semantics?It can, but there are synchronization issues to overcome (with Selector.wakeup()), and generally the cost of solving these is much higher than the cost of a single-threaded selector solution with worker threads for the application processing.

Is the Illustrator SDK thread-safe?

After searching this forum and the Illustrator SDK documentation, I can't find any references to a discussion about threading issues using the Illustrator C++ SDK. There is only a reference in some header files as to whether menu text is threaded, without any explanation.
I take this to mean that probably the Illustrator SDK is not "thread-safe" (i.e., it is not safe to make API calls from arbitrary threads; you should only call the API from the thread that calls into your plug-in). Does anyone know this to be the case, or not?
If it is the case, the normal way I'd write a plug-in to respond to requests from other applications for drawing services would be through a mutex-protected queue. In other words, when Illustrator calls the plug-in at application startup time, the plug-in could set up a mutually exclusive lock (a mutex), start a thread that could respond to requests from other applications, and request periodic idle processing time from the application. When such a request arrived from another application at an arbitrary time, the thread could respond by locking the queue, adding a request to the queue for drawing services in some format that the plug-in would define, and unlocking the queue. The next time the application called the plugin with an idle event, the queue could be locked, pulled from, and unlocked. Whatever request had been pulled could then be serviced with Illustrator API calls. Does anyone know whether that is a workable strategy for Illustrator?
I assume it probably is, because that seems to be the way the ScriptingSupport.aip plug-in works. I did a simple test with three instances of a Visual Basic generated EXE file. All three were able to make overlapping requests to Illustrator, and each request was worked upon in turn, with intermediate results from each request arriving in turn. This was a simple test to add some "Hello, World" text and export some jpegs,
repeatedly.
Any advice would be greatly appreciated!
Glenn Picher
Dirigo Multimedia, Inc.
[email protected]

Zac Lam wrote:
The Memory Suite does pull from a specific memory pool that is set based on the user-specified Memory settings in the Preferences. If you use standard OS calls, then you could end up allocating memory beyond the user-specified settings, whereas using the Memory Suite will help you stick to the Memory settings in the Preferences.
When you get back NULL when allocating memory, are you hitting the upper boundaries of your memory usage? Are you getting any error code returned from the function calls themselves?
I am not hitting the upper memory bounds - I have several customers that have 10's of Gb free.
There is no error return code from the ->NewPtr() call.
     PrMemoryPtr (*NewPtr)(csSDK_uint32 byteCount);
A NULL pointer is how you detect a problem.
Note that changing the size of the ->ReserveMemory() doesn't seem to make any difference as to whether you'll get a memory ptr or NULL back.
btw my NewPtr size is either
     W x H x sizeof(PrPixelFormat_YUVA4444_32f)
     W x H x sizeof(PrPixelFormat_YUVA4444_8u)
and happens concurrently on #cpu's threads (eg 16 to 32 instances at once is pretty common).
The more processing power that the nVidia card has seems to make it fall over faster.
eg I don't see it at all on a GTS 250 but do on a GTX 480, Quadro 4000 & 5000 and GTX 660
I think there is a threading issue and an issue with the Memory Suite's pool and how it interacts with the CUDA memory pool. - note that CUDA sets RESERVED (aka locked) memory which can easily cause a fragmenting problem if you're not using the OS memory handler.

Is the Memory Suite thread safe?

Hi all,
Is the memory suite thread safe (at least when used from the Exporter context)?
I ask because I have many threads getting and freeing memory and I've found that I get back null sometimes. This, I suspect, is the problem that's all the talk in the user forum with CS6 crashing with CUDA enabled. I'm starting to suspect that there is a memory management problem when there is also a lot of memory allocation and freeing going on by the CUDA driver. It seems that the faster the nVidia card the more likely it is to crash. That would suggest the CUDA driver (ie the code that manages the scheduling of the CUDA kernels) is in some way coupled to the memory use by Adobe or by Windows alloc|free too.
I replaced the memory functions with _aligned_malloc|free and it seems far more reliable. Maybe it's because the OS malloc|free are thread safe or maybe it's because it's pulling from a different pool of memory (vs the Memory Suite's pool or the CUDA pool)
comments?
Edward

Zac Lam wrote:
The Memory Suite does pull from a specific memory pool that is set based on the user-specified Memory settings in the Preferences. If you use standard OS calls, then you could end up allocating memory beyond the user-specified settings, whereas using the Memory Suite will help you stick to the Memory settings in the Preferences.
When you get back NULL when allocating memory, are you hitting the upper boundaries of your memory usage? Are you getting any error code returned from the function calls themselves?
I am not hitting the upper memory bounds - I have several customers that have 10's of Gb free.
There is no error return code from the ->NewPtr() call.
     PrMemoryPtr (*NewPtr)(csSDK_uint32 byteCount);
A NULL pointer is how you detect a problem.
Note that changing the size of the ->ReserveMemory() doesn't seem to make any difference as to whether you'll get a memory ptr or NULL back.
btw my NewPtr size is either
     W x H x sizeof(PrPixelFormat_YUVA4444_32f)
     W x H x sizeof(PrPixelFormat_YUVA4444_8u)
and happens concurrently on #cpu's threads (eg 16 to 32 instances at once is pretty common).
The more processing power that the nVidia card has seems to make it fall over faster.
eg I don't see it at all on a GTS 250 but do on a GTX 480, Quadro 4000 & 5000 and GTX 660
I think there is a threading issue and an issue with the Memory Suite's pool and how it interacts with the CUDA memory pool. - note that CUDA sets RESERVED (aka locked) memory which can easily cause a fragmenting problem if you're not using the OS memory handler.

Can use the same thread safe variable in the different processes?

Hello,
Can use the same thread safe variable in the different processes? my application has a log file used to record some event, the log file will be accessed by the different process, is there any synchronous method to access the log file with CVI ?
David

Limiting concurrent access to shared resources can be better obtained by using locks: once created, the lock can be get by one requester at a time by calling CmtGetLock, the other being blocked in the same call until the lock is free. If you do not want to lock a process you can use CmtTryToGtLock instead.
Don't forget to discard locks when you have finished using them or at program end.
Alternatively you can PostDeferredCall a unique function (executed in the main thread) to write the log passing the apprpriate data to it.
Proud to use LW/CVI from 3.1 on.
My contributions to the Developer Zone Community
If I have helped you, why not giving me a kudos?

Native library NOT thread safe - how to use it via JNI?

Hello,
has anybody ever tried to use a native library from JNI, when the library is not thread safe?
The library (Windows DLL) was up to now used in an MFC App and thus was only used by one user - that meant one thread - at a time.
Now we would like to use the library like a "server": many Java clients connect the same time to the library via JNI. That would mean each client makes its calls to the library in its own thread. Because the library is not thread safe, this would cause problems.
Now we discussed to load the library several times - separately for each client (for each thread).
Is this possible at all? How can we do that?
And do you think we can solve the problem in this way?
Are there other ways to use the library, though it is not thread safe?
Any ideas welcome.
Thanks for any contributions to the discussion, Ina

(1)
has anybody ever tried to use a native library from
JNI, when the library (Windows DLL) is not thread safe?
Now we want many Java clients.
That would mean each client makes its calls
to the library in its own thread. Because the library
is not thread safe, this would cause problems.Right. And therefore you have to encapsulate the DLL behind a properly synchronized interface class.
Now the details of how you have to do that depends: (a) does the DLL contain state information other than TLS? (b) do you know which methods are not thread-safe?
Depending on (a), (b) two extremes are both possible:
One extreme would be to get an instance of the interface to the DLL from a factory method you'll have to write, where the factory method will block until it can give you "the DLL". Every client thread would obtain "the DLL", then use it, then release it. That would make the whole thing a "client-driven" "dedicated" server. If a client forgets to release the DLL, everybody else is going to be locked out. :-(
The other extreme would be just to mirror the DLL methods, and mark the relevant ones as synchronized. That should be doable if (a) is false, and (b) is true.
(2)
Now we discussed to load the library several times -
separately for each client (for each thread).
Is this possible at all? How can we do that?
And do you think we can solve the problem in this
way?The DLL is going to be mapped into the process address space on first usage. More Java threads just means adding more references to the same DLL instance.
That would not result in thread-safe behavior.

Newbie: is JSP thread safe?

Similar Messages

Maybe you are looking for