Are page flows thread safe?

Are pageflows thread safe? As in, can I have object level variables that
don't need to be synchronized?
Thanks

Yes page flows are thread safe.

Similar Messages

  • Are WLE libraries thread safe?

    Hi,
    Can we implement multiple threads in c CORBA Servers. Are C libraries thread safe? Can i use pthread to create threads in WLE CORBA C servers
    regards,
    Manoj PG

    JSPs/Servlets are not threadsafe in that one instance of the class is created to handle all requests.
    But only your class attributes are not thread-safe. Local variables are stored for each invocation of the service method, and are thread safe.
    Basically you have to declare all your variables inside a method, and if you call any java methods, pass parameters.
    <%!
      int myNumber;   // class attribute - shared among all calls to this servlet
    %>
    <%
      int myLocalNumber; // local variable to method.  will be threadsafe
    %>In short, yes this code is threadsafe. The key will be the same when you get back from doing your "stuff".
    The only problem would be if two people hit it fast enough to get the same time, and thus the same key.
    Cheers,
    evnafets

  • Are static objects thread safe?

    hi,
    i have seen code that looks like this:
    private static TestObject _to;
    static {
    _to = new TestObject();
    if methods within TestObject contain local variables, will local variables inside _to be threadsafe when hit by 2 requests?
    eg.
    User 1 makes a request to:
    _to.setStuff("abc");
    User 2 make a request to:
    _to.setStuff("def");
    Will User 1's now see "def" instead of "abc"?
    thanks
    - Edward Han
    [email protected]

    so what happens to the local variable holder? if 2
    people access the static variable _to and call
    setStuff() one right after the other, is there a
    chance that the first person in will print out what
    the second person in set as the holder?
    Local variables are thread specific and live on an execution stack, and each thread gets its own stack. If there are two threads, there are two stacks, and if both threads are "in" setstuff(), there are two distinct references called "holder" -- one per stack. And regardless of the order in which the threads enter that method, the references themselves are not clobbered. Now, what you see printed is an entirely different issue, as is the case if the "holder" references point to the same (shared) object.
    The key is this: a thread-specific resource is thread safe; a shared (unprotected and/or mutable) resource is not.

  • 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.

  • Are Static methods Thread safe?

    Hello All
    I have a static method that takes a integer and returns a mathematically processed result.
    Since this method is frequently required, I have placed it in a common class and declared it as static.
    I want to know whether this method is thread safe?

    There's nothing special about static methods, with regard to thread safety. If they access shared objects, then such access will usually need to be controlled by synchronisation; this might be on the object being accessed, some higher-level object or a special object allocated purely as a lock. The only way that you might think of them as special is that there's no instance of the Class on which you can synchronise.
    You can declare a static method as synchronised. If you do, it will be synchronised on the single Class object of the class in which it is declared. This means that only one thread can be executing any part of the method at any one time. However, I understand that the Java Runtime itself sometimes synchronises on this Class object for its own reasons, therefore you might sometimes find a synchronised static method blocks when no other thread is executing it. Usually better, therefore, to explicitly synchronise on some object or other, than to use synchronised static methods.

  • Are SocketFactory implementations thread-safe?

    Hi!
    I'm using a SSLSocketFactory-singleton (SSLSocketFactoryImpl it is I guess) for creating SSLSocket-instances in my application.
    I just wondered whether or not I need synchronization especially for using the createSocket(...)-methods in my multi-threaded application, since I can't look in the code due to restrictions. Another question is whether the answer applies to other SocketFactory implementations.
    Greetings

    georgemc wrote:
    JAVAnetic wrote:
    georgemc wrote:
    Why would you need SocketFactory to be thread-safe anyway?Because, in my multi-threaded application I want to use only one SocketFactory-instance to reduce the overhead of creating one per thread that needs Sockets. So this instance as a shared object used by many threads will need to be synchronized if it is not already thread-safe per se. But all you do with a SocketFactory is ask it for sockets. What issues do you think you'll face with multi-threaded requests for new instances of something? Just because you've got multi-threaded code, doesn't mean everything you use has to be synchronized.I know, but since I don't know what the factory-implementation actually does creating those instances I think it is always worth asking, if I have to synchronize even if it may be true that the design of (the) factory-implementation(s) is in fact thread-safe, which no one until now could tell me for sure.

  • 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 i++, i-- atomic and thread safe for int i

    I want to minimize the sync time multiple threads take to contend for a shared pool, which is implemented as a FIFO. My plan is to:
    1. Use a int variable "count" to trace the free obj count. Hence eliminates the need of synchonized methods size() and isEmpty()
    2. Increment & decrement count when implemeting push() and pop()
    3. Minimize the number of statements in synchonized block as possible within push() and pop(), which in this case, excludes count++ and count-- provided these operations are atomic and thread safe
    Have I lost something ?

    So, may I make a conclusion.
    To minimize contention, I use FIFO instead LIFO or stack and build it from scratch without extending from existing Collection-related class
    1 public class FIFO {
    2 . . private volatile int count;
    3 . . private Object head, tail;
    4 . . public Object pop() {
    5 . . . .synchonized (tail) {
    6 . . . . .if (count >= 3) {
    7 . . . . . .Object tail_origin = tail;
    8 . . . . . .// Re-organizing the linked list skipped
    9 . . . . . .synchonized (this) {
    10 . . . . . . count--;
    11 . . . . . }
    12 . . . . . return tail_origin;
    13 . . . . }
    14 . . . . else {
    15 . . . . . throw new PoolEmptyException();
    16 . . . . }
    17 . . . }
    18 . . }
    19 . . public void push(Object o) {
    20 . . . synchronized (head) {
    21 . . . . . // Re-organizing the linked list skipped
    22 . . . . . head = o;
    23 . . . . . synchonized (this) {
    24 . . . . . . count++;
    25 . . . . . }
    26 . . . }
    27 . . }
    28 . . public int sizeOf() {
    29 . . . return count;
    30 . . }
    31 }
    1. The reason I choose FIFO is to avoid the contention between push() and pop() -- they are NOT declared as synchonized, instead they only lock head and tail respectively. (Sorry I borrow the name push and pop from stack)
    2. pop() only works when count >= 3 to avoid head == tail after pop() and hence a further call to push() block concurrent call to pop() and vice versa (see line 5 and 20)
    3. The goal is to minimize the time and scope of contention. In line 9 and 23, I lock the whole pool object only when modify count, which is not atomic.
    4. This pool is used for a thread pool supporting many concurrent short-lived HTTP request
    Have I missed something ?
    Thanks a lot!

  • Trying to understand "thread-safe" w/ swing components

    The other day there was a big hullabaloo about some code I posted because I was calling JLabel.setText from a thread that wasn't the ui thread. On the other hand, this thread was the only thread making changes to the JLabel. My understanding is that in any kind of multi-threaded system, if you just have 1 writer / changer, then no matter how many readers there are, this is thread-safe. So why what I was doing not thread safe?
    Second question - JLabel.setText() is essentially setting data in the model for JLabel, which then gets picked up and displayed the next time the GUI thread paints it. So if it's not safe to update a JLabel's model, I assume its never safe to update any data that also is being displayed visually. So for instance, if I was showing some database table data in a JTable, I should do the update in the UI thread - probably not. But what is the distinction?
    Third question - what swing components and what operations need to be run on the UI thread to call your program "thread-safe". Validate? setSize()? setLocation()? add? remove? Is there anything that can be called on swing components from a non-ui thread?
    Edited by: tjacobs01 on Nov 2, 2008 8:29 PM

    tjacobs01 wrote:
    My understanding is that in any kind of multi-threaded system, if you just have 1 writer / changer, then no matter how many readers there are, this is thread-safe. So why what I was doing not thread safe?This is not true. As I mentioned in that hullabaloo thread, the Java Memory Model allows threads to cache values of variables they use. This means that values written by one thread are not guaranteed to ever be visible to other threads, unless you use proper synchronization.
    Take the following example:
    import java.util.concurrent.TimeUnit;
    public class ThreadExample {
        static class Foo {
            private String value = "A";
            public String getValue() {
                return value;
            public void setValue(String value) {
                this.value = value;
        public static void main(String[] args) {
            final Foo foo = new Foo();
            Thread writer = new Thread() {
                @Override
                public void run() {
                    try {
                        TimeUnit.SECONDS.sleep(1);
                        foo.setValue("B");
                    } catch (InterruptedException e) {
                        e.printStackTrace();
            Thread reader = new Thread() {
                @Override
                public void run() {
                    try {
                        TimeUnit.MINUTES.sleep(1);
                        System.out.println(foo.getValue());
                    } catch (InterruptedException e) {
                        e.printStackTrace();
            writer.start();
            reader.start();
    }Here two different threads both access the same Foo instance, which is initialized with a value of "A". One thread, the writer, sleeps one second, and then sets foo's value to "B". The other thread, the reader, sleeps one minute (to avoid race conditions) and then prints foo's value to System.out. It may seem obvious that the reader thread will read the value "B", but this is in fact not guaranteed to be true. The reader thread may never see the value that was written by the writer thread, so it may very well read the old value "A".
    (If you run the code you will probably see "B" printed out, but again, this is not guaranteed behavior.)
    A simple way to fix this is to synchronize access to the mutable state that the two threads share. For example, change the class Foo to
        static class Foo {
            private String value = "A";
            public synchronized String getValue() {
                return value;
            public synchronized void setValue(String value) {
                this.value = value;
        }It's for this same reason that you often see the use of a volatile boolean as a control flag for stopping threads, rather than a plain old boolean. The use of volatile guarantees that the thread you want to stop actually sees the new value of the flag once it has been set by another thread.
    Here is an article that touches some of this stuff:
    [http://www.ibm.com/developerworks/java/library/j-jtp02244.html]
    I also highly recommend the book "Java Concurrency in Practice" (one of the authors of which, David Holmes, sometime hangs out on the Concurrency forum here, I believe).
    Edited by: Torgil on Nov 2, 2008 9:01 PM

  • Page flow controller - instance variable thread safe?

    I have page flow controller that is a subclass of org.apache.beehive.netui.pageflow.PageFlowController runing weblogic 921. The essence of my question is: is instance variable of page flow controller thread safe?
    Here are the details. I have an instance variable “status” that stores the status of the patient, which is stored in the request. It sets the status with after the patient status is retrieved from database. The set method is not synchronized.
    This works fine during normal test. But it failed during load test. Does a page flow controller instance shared among different requests? If so, how can I store the status for each request?
    Thanks,
    G T

    Hello
    You seem to put your question on the wrong forum
    Oracle Beehive and Apache Beehive are two different products...
    Have a look on http://beehive.apache.org
    Cheers
    Fred

  • 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.

  • 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.

  • Page Area over flow problem

    Hi,
    When I am executing The Bapi in Ecc6.0 its goes to Short dump.
    Short Dump error is:page area over flow in abap/4 memory.
    This is very Urgent please suggest me how to overcome this short dump.
    regards,
    babu

    hi
    https://forums.sdn.sap.com
    abapcode.blogspot.com
    ABAP/4 programs can take a very long time to execute, and can make other processes have to wait before executing. Here are some tips to speed up your programs and reduce the load your programs put on the system:
    Use the GET RUN TIME command to help evaluate performance. It's hard to know whether that optimization technique REALLY helps unless you test it out. Using this tool can help you know what is effective, under what kinds of conditions. The GET RUN TIME has problems under multiple CPUs, so you should use it to test small pieces of your program, rather than the whole program.
    Generally, try to reduce I/O first, then memory, then CPU activity. I/O operations that read/write to hard disk are always the most expensive operations. Memory, if not controlled, may have to be written to swap space on the hard disk, which therefore increases your I/O read/writes to disk. CPU activity can be reduced by careful program design, and by using commands such as SUM (SQL) and COLLECT (ABAP/4).
    Avoid 'SELECT *', especially in tables that have a lot of fields. Use SELECT A B C INTO instead, so that fields are only read if they are used. This can make a very big difference.
    Field-groups can be useful for multi-level sorting and displaying. However, they write their data to the system's paging space, rather than to memory (internal tables use memory). For this reason, field-groups are only appropriate for processing large lists (e.g. over 50,000 records). If you have large lists, you should work with the systems administrator to decide the maximum amount of RAM your program should use, and from that, calculate how much space your lists will use. Then you can decide whether to write the data to memory or swap space. See the Fieldgroups ABAP example.
    Use as many table keys as possible in the WHERE part of your select statements.
    Whenever possible, design the program to access a relatively constant number of records (for instance, if you only access the transactions for one month, then there probably will be a reasonable range, like 1200-1800, for the number of transactions inputted within that month). Then use a SELECT A B C INTO TABLE ITAB statement.
    Get a good idea of how many records you will be accessing. Log into your productive system, and use SE80 -> Dictionary Objects (press Edit), enter the table name you want to see, and press Display. Go To Utilities -> Table Contents to query the table contents and see the number of records. This is extremely useful in optimizing a program's memory allocation.
    Try to make the user interface such that the program gradually unfolds more information to the user, rather than giving a huge list of information all at once to the user.
    Declare your internal tables using OCCURS NUM_RECS, where NUM_RECS is the number of records you expect to be accessing. If the number of records exceeds NUM_RECS, the data will be kept in swap space (not memory).
    Use SELECT A B C INTO TABLE ITAB whenever possible. This will read all of the records into the itab in one operation, rather than repeated operations that result from a SELECT A B C INTO ITAB... ENDSELECT statement. Make sure that ITAB is declared with OCCURS NUM_RECS, where NUM_RECS is the number of records you expect to access.
    If the number of records you are reading is constantly growing, you may be able to break it into chunks of relatively constant size. For instance, if you have to read all records from 1991 to present, you can break it into quarters, and read all records one quarter at a time. This will reduce I/O operations. Test extensively with GET RUN TIME when using this method.
    Know how to use the 'collect' command. It can be very efficient.
    Use the SELECT SINGLE command whenever possible.
    Many tables contain totals fields (such as monthly expense totals). Use these avoid wasting resources by calculating a total that has already been calculated and stored.
    verify if it can give an idea to the question.

  • 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 methods in Java thread safe?

    Are static methods in Java thread safe?
    thanks,
    suresh

    if static method use the instance variable
    You mean member variable, where member variables are either class variables (static) or instance variables (non-static).
    then you have to make it thread safe using
    synchronization Not necessarily. Depends on requirements and usage context.
    else in case of local var. it
    is thread safe. Not necessarily. That local variable could refer to an object that's visible to multiple threads.
    Statements like "Local variables are threadsafe but member variables aren't" are an oversimplification.
    Something is threadsafe if it cannot be made to behave incorrectly simply by running it in a multithreaded context. Determining that can be very difficult.

Maybe you are looking for