Is session attribute thread-safe?

If i visit the same web application across two browser windows simultaneity, there will be two threads visiting the web application.
But i don't know whether the two threads share the same session?
If they share, the session attribute is not thread-safe.
If they do not share, the session attribute is thread-safe.
who can explain it to me? Thanks a lot!

it depends
we may think that there can be only one request to the session from the one user so the session would be thread safe,However if the user have multiple request (i.e opens more than one browser ), all the request belong to the same session and all threads processing these requests will be able to access the session simultaneously.
to solve this problem we use a synchronized blok to process the session so it will be thread safe from multiple requests from the same user

Similar Messages

BC4J View not Thread safe, user sessions are using the same view instance

Hi There,
We are using BC4J that came with JDeveloper 10.1.2.0.0 with Oracle 10G 10.1.2.0.0.
I have an BC4J account search view (BC4J AccountSearchView) that users can call to search for an account. So this view could be used by numerous users and pieces of code at the same time. Now my understanding is that each user gets their own instance of the view so changing the view's query should not be an issue (since the view definition is not changing). Under a light load the account search view looks like everyone get there own instance of the view and there expected account search results. But under a heavy user load when we have User A and User B the search query that was for User A will be used by User B. So the user results for one user will get the other users results.
I do not understand if the view definition is been changed by the other user and is impacting all view instances. How can this occur if it is thread safe?
I have enclosed the core code for this search.
If you can help that would be much appreciated, thanks in advance,
Nigel
accountSearchView.setQuery(baseSelectQuery+generateWhereClause());
logger.debug("SearchAccounts Query: "+accountSearchView.getQuery());
System.out.println("SearchAccounts SQL: "+accountSearchView.getQuery());
accountSearchView.setPassivationEnabled(false);
accountSearchView.setForwardOnly(true);
accountSearchView.executeQuery();
get attributes for each row result and place in new Java bean objects and return to user.

Nigel, we've only certified JDeveloper 10.1.2 against the Struts 1.1 with which it ships.
If there have been any changes in Struts 1.2 to the Struts Request Processor, then this could easily have an impact on the BC4JRequestProcessor's correct functioning, depending on what the changes were.
My quick look into the issue tells me that the ActionServlet init parameter named mapping in web.xml that we use for the 9.0.3-style BC4J/Struts integration is getting ignored by Struts 1.2. This parameter is used by Struts 1.1 to globally configure a custom ActionMapping subclass which can support additional properties. My quick test shows me that Struts 1.2 is ignoring this setting and so the oracle.jbo.html.struts11.BC4JActionMapping subclass of Struts's default ActionMapping is not getting used correctly as it does in Struts 1.1. This leads to errors when Struts tries to configure its actions in struts-config.xml since the Apache digester tries to set properties on the ActionMapping instance that don't exist (since the BC4JActionMapping has these properties, and it's not being used).
<servlet>
    <servlet-name>action</servlet-name>
    <servlet-class>org.apache.struts.action.ActionServlet</servlet-class>
    <init-param>
      <param-name>mapping</param-name>
      <param-value>oracle.jbo.html.struts11.BC4JActionMapping</param-value>
    </init-param>
</servlet>This is my quick analysis of what's not out-of-the-box compatible. I don't know enough about the changes in Struts 1.2 to know why this Struts 1.1 feature broke in Struts 1.2, or what the Struts 1.2 way to accomplish the same thing is.
I'd encourage you to use Worldwide Support's Metalink site and open a TAR for any time-critical issues you need assistance in resolving. Many of us are constantly traveling and only able to sporadically chime in with tips in the forum as our time permits.
The source of the BC4JRequestProcessor ships with the produce in the ./BC4J/src directory inside the bc4jstrutssrc.zip file.

Session Manager not thread safe

We are running 6.0 web server with IWSSessionManager turned on. We have the failover set to true so that we always load from the persistent store.
We had a situation where a frame set invoked 2 requests to the application. The logic in the session manager seems to be for each request:
1) the session is loaded from the database.
2) the new session overwrites the session in memory.
3) the servlet/jsp uses that session.
4) that session is persisted.
Now.. if only one of the requests actually modifies the session then threadA and threadB have 2 session instances which have unique objects with the same session id. The last one to complete is stored in the database. This would result in data loss. (btw.. the code in question is IWSSessionManager.getSession(String id, ServletContext context)).
Has anyone else seen this, or have we set up something really wacky?
Thanks!
-- bk

c

Is abap thread safe? Some question in Singleton pattern in ABAP

Hi Grus,
I have a very basic question but really make me headache...
Recently I am learning the design pattern in ABAP and as you know in JAVA there is a key word "Synchronized" to keep thread safe. But in ABAP, I didn't find any key words like that. So does that mean ABAP is always a single thread language? And I found that there is a way looks like "CALL FUNCTION Remotefunction STARTING NEW TASK Taskname DESTINATION dest" to make multi-thread works. As you can see it use the destination, so does that mean actually the function module is always executed in a remote system, and in every system, it is always single thread?
Could you help me on the question? Thanks a lot, grus
And here comes up to my mind another question...It's a little bit mad but I think it may works....What if I set every attribute and method as static in the singleton class...Since as you can see it is already a singleton so every attribute in it should be only one piece. So then I don't even need to implement a get_instance( ) method to return the instance. Just call "class_name=>some_method( )" directly then singleton is achieved...What do you think?
BR,
Steve

Steve,
I've the same question, few days ago I tried to use the singleton in ABAP. In Java programming is possible to use the same reference in two sessions or programs, sharing attributes, methods and all data, but I could not do in ABAP.
In my test I created a program with one global class using the singleton pattern, so I expected that when I run my program and see the reference returned after the get_instance method it should be equal to the same program run in another session, but the ABAP will create a new reference and instantiate again.
So I deduced that the only way to share it between sessions in ABAP is using the ABAP Shared Memory Objects.
I can be wrong, but I think that ABAP use a thread by user session (Each window) and we can't change it.
Best regards.

Thread-Safe BC4J Application

Hello,
I have an BC4J-based application, based on BC4J9.0.2. I'm considering to upgrade my BC4J library to upper version to make my application more thread-safe.
How can I make thread-safe application using BC4J? Is there any specific Rule?
Thank you.

Hi,
Its hard to define a single rule since it depends upon how each application is using threads. I have included some thoughts about the most common scenarios for web clients below:
The BC4J client wizards (datatags, struts, JClient) will help you generate threadsafe applications. The general rule when writing a web client is to ensure that each "user", as represented by an HttpSession instance, has their own ApplicationModule instance. Using the ApplicationModule datatag or the BC4J/Struts framework will guarantee this.
Beyond this it may also be necessary to coordinate multiple concurrent requests from a single client (imagine a user pounding on the browser refresh button). One approach for solving this problem is to synchronize requests on some sort of session context. The ApplicationModule tag supports a latching mode (see the lock attribute) which performs this by synchronizing access to the SessionCookie (cached in session, used to acquire ApplicationModule instance). Support for latching will also be available in Struts in the 9.0.3.3 and later timeframe.
Hope this helps,

Need thread safe way to access read-only objects

I have been working on a lot of projects and all the developers agree that they want thread safe code when called by many threads. It's rare developers are making statement like: "Data are not corrupted often so don't bother" or "It's not thread safe, but that will not often create issues".
In TopLink client session itself is thread safe but not the persistent object themselves. Via client session, if you want thread safe access you need to put a lock on CacheKey and it's not a public/supported API. So the only thread safe access is via unit of work.
We would like fast access to objects. We have a batch process that just need read-only access to objects. We need to read via unit of work to get thread safe access. But we just need the clone when we read via unit of work, we don't need the backup for change detection.
However, TopLink doesn't have a mean to do that.
Please push implementation of Bug5998333[WANT THREAD SAFE AND CORRECT ISOLATION WITH OBJECTS FROM ADDREADONLYCLASS]
In Hibernate, by design, all access are always thread safe. Accessing read-only object just create one copy (a clone), no backup needed.
Oracle claims that TopLink is fast. I wonder if their performance testing code is thread safe, so access objects via unit of work or they take the shortcut of accessing objects from client session. Also, reliable performance comparison should use conform in unit of work.

As you stated the UnitOfWork offers you your desired functionality, you would just like an improvement in performance.
In TopLink 10.1.3 (or 11g preview) you have a few options:
- Use a UnitOfWork an live with the slight overhead of the back copies (it will only add 5-30 % overhead to your processing)
- Instead use an isolated client session, this will not require any cloning or backup clones, but also does not allow any caching.
- Use change tracking, TopLink added attribute-level change tracking in 10.1.3, when used the UnitOfWork does not create backup clones. In 10.1.3 it was mainly used for CMP and requires code generation, but you could implement or weave the code yourself. In TopLink 11g, change tracking is weaved by default with JPA and the weaver can also be used with POJO objects.
I agree that having a feature to mark an object as transactionally read-only would be desirable, it seems like you have logged the enhancement. You could try escalting the enhancement through Oracle support, but since it is an enhancement and not a bug, it is probably beyond what support offers. You may wish to investigate services, or potentially join the open source Eclipse EclipseLink project which the next version of TopLink is being developed under and take part in the feature yourself.

Is pipelinesession access thread safe?

Generally speaking, when we access session object in a servlet which is multithreaded,
e.g. session.setAttribute(), developers need to use the "synchronized" keyword
to ensure thread safety.
However wen we use setSessionAttribute() to add attributes into pipeline session,
do we still need to use "synchronize" to make sure the method is thread safe??
Same question applies to <webflow:setProperty>.
Is there any other place in a portal app I should pay attention about thread safe?
Thank you for all your input!
Ellen

Although you don't see these methods marked "synchronized", the
implementation is thread-safe. So, you don't need to explicitly
synchronize calls to this interface.
Subbu
Ellen wrote:
Generally speaking, when we access session object in a servlet which is multithreaded,
e.g. session.setAttribute(), developers need to use the "synchronized" keyword
to ensure thread safety.
However wen we use setSessionAttribute() to add attributes into pipeline session,
do we still need to use "synchronize" to make sure the method is thread safe??
Same question applies to <webflow:setProperty>.
Is there any other place in a portal app I should pay attention about thread safe?
Thank you for all your input!
Ellen

Is Persistence context thread safe? nop

In my code, i have a servlet , 2 stateless session beans:
in the servlet, i use jndi to find a stateless bean (A) and invoke a method methodA in A:
(Stateless bean A):
@EJB
StatelessBeanB beanB;
methodA(obj) {
beanB.save(obj);
(Stateless bean B, where container inject a persistence context):
@PersistenceContext private EntityManager em;
save(obj) {
em.persist(obj);
it is said entity manager is not thread safe, so it should not be an instance variable. But in the code above, the variable "em" is an instance variable of stateless bean B, Does it make sense to put it there using pc annotation? is it then thread safe when it is injected (manager) by container?
since i think B is a stateless session bean, so each request will share the instance variable of B class which is not a thread safe way.
So , could you please give me any guide on this problem? make me clear.
any is appreciated. thank you
and what if i change stateless bean B to
(Stateless bean B, where container inject a persistence context):
@PersistenceUnit private EntityManagerFactory emf;
save(obj) {
em = emf.creatEntityManager()
//begin tran
em.persist(obj);
// commit tran
//close em
the problem is i have several stateless beans like B, if each one has a emf injected, is there any problem ?

Hi Jacky,
An EntityManager object is not thread-safe. However, that's not a problem when accessing an EntityManager from EJB bean instance state. The EJB container guarantees that no more than one thread has access to a particular bean instance at any given time. In the case of stateless session beans, the container uses as many distinct bean instances as there are concurrent requests.
Storing an EntityManager object in servlet instance state would be a problem, since in the servlet programming model any number of concurrent threads share the same servlet instance.
--ken

How to make a global scope component to be thread safe?

One of my global component preserves states in its member variables, I am afraid that it's might messed up in multi-threading conditions, so how to make a nucleus global component to be thread safe?
Edited by: user13344577 on Jul 14, 2011 9:45 AM

Hi,
Just to help integrate Shaik's and my own seemingly contradictory replies:
If the member variables in your global component actually need to be globally available, so that multiple threads/sessions need to seem the same data, then you need to use synchronization or some scheme to make this data thread-safe when updating it. If the member variables are non-global data and are simply for convenience of having data available for multiple method calls or something like that, then you should do as I said (don't use synchronization) and use one of my suggestions to avoid this.
I have seen customers frequently do what I replied about and store non-global data in a global component, and Shaik simply interpreted what "user13344577" is trying to do differently. Clarification is needed to know which of our answers better applies.
Thanks.
Nick Glover
Oracle Support for ATG Products

HTTP request/response object not thread safe.

According to the serlvet spec. Http Request/Response
are not thread safe. Quoting from the Spec:
" Implementations of the request and response objects are not guaranteed to be thread safe. This means that they should only be used within the scope of the request handling thread. References to the request and response objects must not be given to objects executing in other threads as the resulting behavior may be nondeterministic."
This has prompt me to ask the following question.
For Example I have a servlet which does the following
request.setAttribute("myVar","Hello");
The request and response is dispatched(using RequestDispatch.include(request,response)) to another
servlet which retrieve this attribute i.e request.getAttribute("myVar");
Is this safe?
The Spec only said "The Container Provider must ensure that the dispatch of the request to a target
servlet occurs in the same thread of the same VM as the original request." I take this meaning that the targeting servlet does not have to run in the same thread(only dispatch), otherwise it would be safe.

To put it another way, you can only have onle thing working on a request at a time. For instance, the ServletContext is available to all servlets running on a server. If you tried to save a particular request to the ServletContext, it would potentially be available to many concurrently running servlets. They could all change whatever in it at the same time. Each servlet is in its own running thread. Hope that helps some.

List of Non-thread safe system calls in Solaris 2.6??

Hi,
I'm searching for a list of system calls which are known to be non thread safe in a multithreaded process in Solaris 2.6. Anyone know of such a list?

I'm not aware of any list but you can easily find the list by looking for the following pattern in the man pages :-)
| ATTRIBUTE TYPE| ATTRIBUTE VALUE|
|__________________________________
| MT-Level | Unsafe |
|_______________|_________________|
HTH
Angelo
Sun Developer Support.

Are CacheStore's and BackingMapListener's thread safe?

I'm implementing a JMS CacheStore and have a quick question: does Coherence ever attempt to run multiple threads concurrently across a CacheStore instance on a given node?
Reason I ask is that only certain objects are thread-safe in the JMS spec.: Connection Factories, Destinations (i.e. a Queue) and Connections. However Sessions, Producers and Consumers are not.
In order to improve performance, it's recommended (obviously) to try and reuse Sessions/Producers and not recreate them for every message sent. So I'd like to declare them as instance variables in my class and assign them once-only at construction time.
I just wanted to make sure that this would be OK (i.e. Coherence would start multiple threads running across my CacheStore). Anyone any ideas?
(NB. I'm using JMS Connection Pooling to get around this issue at the moment - as the pools are thread-safe and I can close/open them quickly as many times as I like - but this is not a part of the JMS standard, so I end up using vendor-specific classes which I'd rather not do. Likewise I could make many of these non-thread-safe objects use ThreadLocals, but this all seems a bit overkill if it isn't actually required...)
An other issue... :)
What about closing the connection when it's finished with? Again, it's JMS recommended best-practice to do so. How is this best accomplished, seem as though it was Coherence that created the CacheStore instance and my client code has no reference to it? Best I can think of for now is have a static method in my CacheStore class that is kicked off via an invocation-service agent. Again, if anyone has a better idea I'm all ears.
An other issue... :)
Does the same thread-safety hit BackMapListeners? The "receiving" end of my JMS messages is a BackingMapListener based on the Incubator Commons "AbstractMultiplexingBackingMapListener" class. So, does Coherence ever kick off multiple threads across a single BackingMapListener instance, or can I safely have the JMS Session and Consumer left open after construction as class-level members?
Cheers,
Steve

stevephe wrote:
True... But I was rather hoping I could just get someone from Oracle who wrote the stuff to comment instead! :) Don't really want to second-guess this, as there could always be unusual corner-cases that could be difficult to replicate. Still...
I did a bit more testing on my CacheStore this morning. I removed the non JMS-standard "pooling" and just created instance variables for only those items which I know to be thread-safe (ConnectionFactory, Connection and my target queue, a "Destination" in JMS terminology) I now re-get the Session and Producer in each Cachestore method. This makes the code thread-safe and portable. TBH, it hasn't affected performance too much, so I'll leave it as it is for now (and I've put a comment in the code stating that people could move these things to ThreadLocal's if they wanted to further boost performance in their own usage cases and still keep the CacheStore thread-safe.)
As regards the "receiving" end of these published messages, my BackingMapListener does nothing more than register a JMS MessageListener and a "connection.start()" call. This is a very short, one-off call, so shouldn't leave Coherence service threads "hanging" on anything for extended periods.
Cheers,
SteveHi Steve,
to cut things short:
1. Coherence instantiates one cache store per read-write-backing-map, therefore it needs to be thread-safe if you have a thread-pool or use write-behind.
2. If you don't have write-behind then Coherence uses the worker thread to execute the cache store operations.
3. If you have write-behind then generally Coherence uses the write-behind thread (this is a separate thread per write-behind-configured service) to execute the cache store operations, except for erase[All]() operations on cache.remove() or batch remove which cannot be delayed due to consistency reasons and are executed on the worker thread.
If you don't have a thread-pool, replace worker thread with service thread.
I don't know off my head where the refresh-ahead operation executes.
There is a single backing-map-listener per backing map instantiated, therefore it needs to be thread-safe. BackingMapManagerContext is thread-safe, so there is no issue with sharing it across multiple threads executing on a backing-map-listener.
Best regards,
Robert

Are static nested classes thread-safe?

There doesn't seem to be any definitive answer to this. Given the following code, is it thread-safe?
public class SomeMultiThreadedWebController {
public HttpServletResponse someMethodToExecuteViaWebRequest(HttpServletRequest request) {
    simpleQueryBuilder("SELECT...").addParameter("asdf","asdf").createQuery(EMF.getEntityManager()).executeUpdate();
protected static class SimpleQueryBuilder {
         private String queryString;
         private Map<String, Object> params = new HashMap<String, Object>();
         public SimpleQueryBuilder(String queryString) {
              this.queryString = queryString;
         public SimpleQueryBuilder addParameter(String name, Object value) {
              params.put(name, value);
              return this;
         public Query createQuery(EntityManager em) {
              Query query = em.createQuery(queryString);
              for (Entry<String, Object> entry : params.entrySet()) {
                   query.setParameter(entry.getKey(), entry.getValue());
              return query;
    public static SimpleQueryBuilder simpleQueryBuilder(String queryString) {
         return new SimpleQueryBuilder(queryString);
}Forget whether or not someone would do this, as this is just an example. I'm really trying to get at whether or not the instance variables inside the static nested class are thread-safe. Thanks for any responses.

Hello,
I believe you understand what you're talking about, but you state it in a way that is very confusing for others.
Let me correct this (essentially, incorrect uses of the terminology):
I agree that thread-safe or not is for an operation, for a member, it has some sort of contextual confusion.
Member has a much broader meaning in the [Java Language Specification|http://java.sun.com/docs/books/jls/third_edition/html/names.html#6.4] . Even "class member" applies to both an attribute, a method, or an inner class or interface.
I think you mean "member variable" of a class (aka "attribute" or "field"). By the way, static or not is irrelevant to the rest of the discussion.
For an operation or a member, if there's only one thread could access it atomically in one moment, we could call it thread-safe.Mmm. I was tempted to say yes (I'm reluctant to commit myself). With an emphasis on "_The encapsulating class_ makes this member's usage thread-safe".
Still, just synchronizing each operation on a member is not enough to make all usages "thread-safe":
Consider a java.util.Vector: each add/get is synchronized, so it is atomic, fine.
However if one thread adds several values, let's say 3, one by one, to a vector that initially contains 0 values, and another thread reads the vector's size() (another properly synchronized method), the reader thread may witness a size anywhere among 0, 1, 2, 3, which, depending on the business logic, may be a severely inconsistent state.
The client code would have to make extra work (e.g. synchronizing on the vector's reference before the 3 adds) to guarantee that the usage is thread-safe.
Thus any synchronized method(With the limit stated above)
or immutable member (like primitive type) are thread-safe.
Additionally for a member, if it's immutable, then it's thread-safe. You mean, immutable primitive type, or immutable object. As stated previously, an immutable reference to a mutable object isn't thread-safe.
a static final HashMap still have thread-safe issue in practice because it's not a primitive.The underlined part is incorrect. A primitive may have thread-safety issues (unless it's immutable), and an object may not have such issues, depending on a number of factors.
The put, get methods, which will be invoked probably, are not thread-safe although the reference to map is.Yes. And even if the put/get methods were synchronized, the client code could see consistency issues in a concurrent scenario, as demonstrated above.
Additional considerations:
1) read/write of primitive types are not necessarily atomic: section [ §17.7 of the JLS|http://java.sun.com/docs/books/jls/third_edition/html/memory.html#17.7] explicitly states that writing a long or double value (2 32-bits words) may not be atomic, and may be subject to consistency issues in a concurrent scenario.
2) The Java Memory Model explicitly allows non-synchronized operations on non-volatile fields to be implemented in a "thread-unsafe" way by the JVM. Leading way to a lot of unintuitive problems such as the "Double-Checked Locking idiom is broken". Don't make clever guess on code execution path unless you properly synchronize access to variables across threads.
Edited by: jduprez on Mar 4, 2010 9:53 AM

Which is thread safe

If I implement SingleThreadedModel in a servelt which are all thread safe?
Request object, response object, instance variables,class variables( by the by can i have class variables in a Servlet ? how/where it will be used?)

If you use SingleThreadModel, everything will be thread safe, because you are spawning one instance of the servlet, for every request. This WILL NOT scale well if you have many users at once.
With regard to what is thread safe in a normal servlet, I believe
request
response
session
variables local to functions
NOT safe:-
class variables - these will be shared by multiple instances.

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

Is session attribute thread-safe?

Similar Messages

Maybe you are looking for