Use of volatile

public class MyClass {
     public static void main(String[] a) throws InterruptedException {
          new Thread(new A(),"thread1 ").start();
          Thread.sleep(500);
          new Thread(new A(),"thread2 ").start();
class A implements Runnable {
     volatile int value = 0;
     public void run() {
          value++;
          System.out.println(Thread.currentThread().getName() + value);
}Hi, I tried running this code with value being both volatile and not, but I get the same answer each time. Both threads turn value to 1. Shouldn't volatile make it 1 then 2?
I tried the same thing but making value static, in which case it works as I thought it would have worked with volatile. I'm not too sure what volatile does anymore, could somebody please help clarify all this for me?
Thanks.

public class MyClass implements Runnable {
     Other o = new Other();
     public static void main(String[] a) throws InterruptedException {
          MyClass m = new MyClass();
          new Thread(m,"thread1 ").start();
          Thread.sleep(500);
          new Thread(m,"thread2 ").start();
     public void run() {
          o.value++;
          System.out.println(Thread.currentThread().getName() + o.value);
class Other {
     volatile int value;
}I looked at this one a bit longer, and I came up with this new example. Is this case more likely to need the volatile keyword as a precaution (as the variable in question is in an indepedent class)?
Any help on this topic would be really appreciated. I looked up several websites on volatile, but none really clarified the use of volatile (actually, I don't recall whether any mentioned that the caching problem doesn't always happen!).
Thanks.

Similar Messages

  • What is the use of Volatile Key word ??

    what is the use of Volatile Key word ??
    There is a primitive variable
    volatile int b = 10; // this is a master copy
    Locally thread A changes this int b as 5.
    Locally thread B changes this int b as 20.
    thread c want to use this int b.
    now what c will get??
    If didn't use volatile what will happen.
    Regards
    Dhinesh

    Deenu wrote:
    what is the use of Volatile Key word ??Why don't you ever reply to any of your threads? You never thank anyone for helping you, and this makes you one of the worst trolls out there.

  • Use of volatile modifier

    can any one explain me the use of volatile modifier

    What does volatile do?
    This is probably best explained by comparing the effects that volatile and synchronized have on a method. volatile is a field modifier, while synchronized modifies code blocks and methods. So we can specify three variations of a simple accessors using those two keywords:
    int i1; int geti1() {return i1;}
    volatile int i2; int geti2() {return i2;}
    int i3; synchronized int geti3() {return i3;}
    geti1() accesses the value currently stored in i1 in the current thread. Threads can have local copies of variables, and the data does not have to be the same as the data held in other threads. In particular, another thread may have updated i1 in it's thread, but the value in the current thread could be different from that updated value. In fact Java has the idea of a "main" memory, and this is the memory that holds the current "correct" value for variables. Threads can have their own copy of data for variables, and the thread copy can be different from the "main" memory. So in fact, it is possible for the "main" memory to have a value of 1 for i1, for thread1 to have a value of 2 for i1 and for thread2 to have a value of 3 for i1 if thread1 and thread2 have both updated i1 but those updated value has not yet been propagated to "main" memory or other threads.
    On the other hand, geti2() effectively accesses the value of i2 from "main" memory. A volatile variable is not allowed to have a local copy of a variable that is different from the value currently held in "main" memory. Effectively, a variable declared volatile must have it's data synchronized across all threads, so that whenever you access or update the variable in any thread, all other threads immediately see the same value. Of course, it is likely that volatile variables have a higher access and update overhead than "plain" variables, since the reason threads can have their own copy of data is for better efficiency.
    Well if volatile already synchronizes data across threads, what is synchronized for? Well there are two differences. Firstly synchronized obtains and releases locks on monitors which can force only one thread at a time to execute a code block, if both threads use the same monitor (effectively the same object lock). That's the fairly well known aspect to synchronized. But synchronized also synchronizes memory. In fact synchronized synchronizes the whole of thread memory with "main" memory. So executing geti3() does the following:
    1. The thread acquires the lock on the monitor for object this (assuming the monitor is unlocked, otherwise the thread waits until the monitor is unlocked).
    2. The thread memory flushes all its variables, i.e. it has all of its variables effectively read from "main" memory (JVMs can use dirty sets to optimize this so that only "dirty" variables are flushed, but conceptually this is the same. See section 17.9 of the Java language specification).
    3. The code block is executed (in this case setting the return value to the current value of i3, which may have just been reset from "main" memory).
    4. (Any changes to variables would normally now be written out to "main" memory, but for geti3() we have no changes.)
    5. The thread releases the lock on the monitor for object this.
    So where volatile only synchronizes the value of one variable between thread memory and "main" memory, synchronized synchronizes the value of all variables between thread memory and "main" memory, and locks and releases a monitor to boot. Clearly synchronized is likely to have more overhead than volatile.
    I got the above information from the below link......
    http://www.javaperformancetuning.com/news/qotm030.shtml
    and also we can describe the volatile modifier as
    Volatile� A volatile modifier is mainly used in multiple threads. Java allows threads can keep private working copies of the shared variables(caches).These working copies need be updated with the master copies in the main memory.
    But possible of data get messed up. To avoid this data corruption use volatile modifier or synchronized .volatile means everything done in the main memory only not in the private working copies (caches).( Volatile primitives cannot be cached ).
    So volatile guarantees that any thread will read most recently written value.Because they all in the main memory not in the cache�Also volatile fields can be slower than non volatile.Because they are in main memory not in the cache.But volatile is useful to avoid concurrency problem.
    This above information i got from
    http://cephas.net/blog/2003/02/17/using-the-volatile-keyword-in-java/
    Thats all i think you understood what a volatile modifier is.And if you got any doubts still in Java you can reach me to [email protected]
    With Regards,
    M.Sudheer.

  • Use of volatile for variable in jdk 1.6 on Linux platforms

    Hello,
    I run the following code on my computer (dual core). This code just create two threads: one adds one to a value contained in
    an object and the other subbs one to it :
    // File: MultiCore.java
    // Synopsis: At the end of some executions the value of a is not equal
    // to 0 (at laest for one of teh threads) even if we do the
    // same number of ++ and --
    // Java Context: java version "1.6.0_11"
    // Java(TM) SE Runtime Environment (build 1.6.0_11-b03)
    // Java HotSpot(TM) Server VM (build 11.0-b16, mixed mode)
    // Linux Context: Linux 2.6.27-12-generic i686 GNU/Linux
    // Author: L. Philippe
    // Date: 03/10/09
    class MaData {
    public int a;
    public MaData() { a = 0; }
    public synchronized void setA( int val ) { a = val; }
    public synchronized int getA() { return a; }
    class MonThread extends Thread {
    MaData md;
    int nb, nb_iter;
    public MonThread( MaData ref, int rnb )
         md = ref;
         nb = rnb;
         nb_iter = 1000;
    public void run()
         if ( nb == 0 ) {
         for ( int i = 0 ; i < nb_iter ; i++ ) {
              // Increment MaData
              md.setA( md.getA()+1 );
         } else {
         for ( int i = 0 ; i < nb_iter ; i++ ) {
              // Decrement MaData
              md.setA( md.getA()-1 );
         System.out.println( Thread.currentThread().getName() + " a= " + md.a);
    public class MultiCore {
    volatile static MaData md;
    public static void main(String args[])
         try {
         // Data to be shared
         md = new MaData();
         MonThread mt1 = new MonThread( md, 0 );
         MonThread mt2 = new MonThread( md, 1 );
         mt1.start();
         mt2.start();
         mt1.join();
         mt2.join();
         } catch ( Exception ex ) {
         System.out.println( ex );
    This is the result i got:
    Thread-0 a= -734
    Thread-1 a= -801
    This ok for the first one but the second should obviously be 0. For me that mean that the volatile does not work and the threads just access to their cache on different cores. Can someone check that ?
    Thanks,
    Laurent

    Why should the second line obviously be zero?
    I don't think even if you make 'a' volatile that setA(getA() + 1) suddenly becomes atomic, because it becomes:
    int temp = getA();
    // if other thread update a, temp does not get updated
    temp = temp + 1;
    setA(temp);So you'll need a synchronized in/decrement methods on MaData or use an AtomicInteger.

  • Use of volatile modifier in Serialization

    can any body explain me the use of this modifier in Serialization

    Volatile does not effect serialization.
    "transient" means the field is not serialized.

  • Using a variable in two threads...

    i am new to java and have a thread question.
    i am using a GUI and then run a swingworker thread to get updates from a server on a regular basis.
    i realize that if the GUI is updated within the swingworker thread i need to use the invokeLater to put it on the EDT.
    but what if i have a boolean variable declared in the main class that i use within the swingworker thread.
    in other words both the EDT and the swingworker thread might use or set the variable.
    does this variable need to be declared in any special way?
    boolean isOn = false; (how i am declaring)
    so one case would be where the EDT sets the variable true or false and the swingworker thread simply checks the state of the variable.
    if (isOn) (do this);
    else (do that);
    in another case both the EDT and the swingthread check and set the var.
    if (isOn) { Thread.sleep(10);}
    isOn = true;
    isOn = false;
    im new to java so just trying to see if this is ok and if i need to declare isOn as syncronized or something.
    not sure if this will work

    There's no need to use both volatile and
    synchronized. Either declare the variable as volatile
    (*), or use synchronization when reading/writing it.
    (*) At least in theory, I'm not sure this has ever
    been guaranteed to work in practice. In any case,
    volatile is superfluous if you use synchronization.You need to use volatile keyword if do not want that compiler optimizes
    you code in multithread applications.
    For example:
        private boolean isDataChanged;
        void setDataChanged(boolean dataChanged){ isDataChanged = dataChanged; }
        boolean isDataChanged(){ return isDataChanged; }
        void someMethod(){
         isDataChanged = false;
         // some code which does not change isDataChanged variable
         if(isDataChanged){
             // code block 1
         }else{
             // code block 2
        }Compiler can optimize someMethod method to the next code because
    isDataChanged is false in if-else statement:
        void someMethod(){
         isDataChanged = false;
         // some code which does not change isDataChanged variable
         // code block 2
        }But isDataChanged viariable can be changed by another thread
    in multifreads applications so optimization will not be correctly
    because isDataChanged can be true in if-else statement.

  • Core dump using iostream with Sun Studio 8

    I'm running on Solaris 9 using C++ compiler Sun Studio 8, and encoutered a very strange problem.
    My application failed with a core and here is the stack.
    [1] t_splay(0x3774b470, 0x387a0ec0, 0x389aec60, 0x39e5ef1f, 0x3774b470, 0x1), at 0xfc347930
    [2] t_delete(0x387a0ec0, 0x80, 0x39be9748, 0x20, 0x383ccd20, 0x0), at 0xfc347698
    [3] mallocunlocked(0x80, 0x0, 0x21b08, 0xfc3bc000, 0x10, 0x20), at 0xfc346d40
    [4] malloc(0x80, 0xfbaa7400, 0x1, 0x759c40, 0x0, 0x0), at 0xfc346b74
    [5] operator new(0x80, 0x0, 0xd3a18, 0x759c74, 0x0, 0x8345fc), at 0x760c10
    [6] strstreambuf::overflow(0xf41f6e28, 0x29, 0xf41f6e28, 0x39fe0e88, 0x39fe0e88, 0x8345fc), at 0x75bb1c
    [7] streambuf::xsputn(0xf41f6e28, 0xfee00bc0, 0x1, 0x0, 0x81010100, 0x1), at 0x75ab94
    [8] unsafe_ostream::outstr(0xf41f6e78, 0xfee00bbf, 0x0, 0x0, 0xf41f6e7c, 0xfffffffe), at 0x757bac
    =>[9] unsafe_ostream::operator<<(this = 0xf41f6e78, _s = 0xfee00bbf ")"), line 1211 in "iostream.h"
    [10] ostream::operator<<(this = 0xf41f6e74, _s = 0xfee00bbf ")"), line 1350 in "iostream.h"
    [11] CorInterfaceEntity::ifState(this = 0x1bc3de78, newState = MISMATCH_OF_INSTALLED_AND_EXPECTED, needToSendEvent = false
    Can somebody help me giving a direction of investigation ?
    Is there perhaps known problem with iostream on Sun Studio 8 running on Solaris 9 ?
    Thanks for any tips.
    Yaakov Berkovitch
    [email protected]

    But sorry for my insistence, but do you think that
    purify or/and runtime are not able to detect any
    corruption of the heap ?They can detect some kinds of corruption, such as some uses of an invalid pointer.
    But a wild pointer that changes the value of data that is part of your program cannot be detected by RTC or Purify. Those programs can't know whether that change is intentional.
    >
    BTW, we are not using any volatile declaration, and weIf non-local data is shared among threads, it should be declared volatile. For example, suppose you have
    x = foo;
    ... // code not changing foo
    y = foo;
    If foo is not marked volatile, the compiler is allowed to assume its value hasn't changed, and assign to y the same value assigned to x. If foo was changed by another thread, y will not have the current value of foo. The "volatile" declaration says that the variable's value might change without any obvious reason, and the compiler should generate code to load a fresh value each time it is referenced.
    are using the rwtools library packaged with the
    compiler, and are not using the STD library.OK, you are not running into a std::string synchronization bug.
    >
    Also about the compiler option -xarch=v8, is probably
    not relevant for us because we are running Solaris 9.
    So the relevant compiler is probably -xarch=v9. Do you
    advise us using this option ?I think you misunderstand. The -xarch values refer to the kind of processor your program will run on.
    The -xarch=v8 option generates 32-bit code that will run on all SPARC chips, including the chips found in very old SPARCstations. This option is the default for compilers prior to Sun Studio 9 (which ships this week).
    The -xarch=v8plus option generates 32-bit code that runs only on UltraSPARC chips, found in Ultra workstations. These are the only kinds of workstations shipped by Sun since about 1996. Unless you need to support the ancient SPARCstations, we recommend compiling with -xarch=v8plus, to get smaller and faster code.
    The -xarch=v9 option generates 64-bit code that runs only on UltraSPARC chips, an only on Solaris 7 or later. Unless your program requires a very large address space, you generally don't want to generate 64-bit code. On SPARC, 64-bit code is larger and slower than 32-bit code. (Type "long" and all pointers are 64 bits instead of 32 bits.)
    >
    Also I want to return you two new questions:
    1) I read in another discussion,
    http://forum.sun.com/thread.jsp?forum=5&thread=18124&me
    sage=47854#47854
    that another memory manager can be more efficient in
    multi-threaded environment (libmtmalloc.so), and also
    an alternate threads library (/usr/lib/lwp) that
    reduced CPU usage. Do you advice us using this
    alternate library ?The libmtmalloc library usually has better performance in MT programs than the default version of malloc. It also can result in more memory fragmentation. In that case, the larger working set can sometimes have a large negative effect, more than offsetting the MT efficiency. You have to experiment to see whether it is appropriate for your particlular program. If you are running into heap corruption, the pattern of corruption will probably be different with libmtmalloc than with the default malloc. The differences might provide a clue to what is wrong.
    The alternative "T2" threads library was introduced in Solaris 8 as an option.
    In Solaris 9 it is the default, so you are already using it.
    >
    2) We are using the Rogue Wave library shiped with the
    compiler. Is it an up-to-date version ? Can we assume
    that is a good choice or it will be preferable to move
    to the STD library ?I assume you mean Rogue Wave Tools.h++. As explained in the compiler docs, this version of Tools is obsolete, and has not been supported for many years. We continue to provide it for customers who used it before the introduction of the C++ Standard Library in 1998, and who don't want to change their code. We do not recommend it for use in new code.

  • Recent files and volatile user

    Hello:
    We use a volatile user with Zenworks 6.5 so the list of recent files gets wiped off once a user logs out. Is there anyway to change that? We would like to still use a volatile user accoutns, but we would also be able to keep the list of recently opened files so the user can use it after they log off. Thank You.

    Jakub Gorecki,
    > We use a volatile user with Zenworks 6.5 so the list of recent files gets wiped off once a user logs out. Is there anyway to change that? We would like to still use a volatile user accoutns, but we would also be able to keep the list of recently opened files so the user can use it after they log off. Thank You.
    You can move the location of "recent" through the registry. Move it to the user's home directory.
    http://support.microsoft.com/kb/242557
    - Anders Gustafsson, Engineer, CNE6, ASE
    NSC Volunteer Sysop
    Pedago, The Aaland Islands (N60 E20)
    Novell does not monitor these forums officially.
    Enhancement requests for all Novell products may be made at
    http://support.novell.com/enhancement
    Using VA 5.51 build 315 on Windows 2000 build 2195

  • When is volatile needed?

    I know you need to use the volatile keyword when multiple threads might be accessing a primitive or reference without external synchronization. Suppose your class implements Runnable and has one member variable, a final int. The constructor takes an int and simply assigns it to the one member variable. You dump it into an ExecutorService with submit()--do you need to use volatile to make sure that the other threads see the assigned value of the int? The int is only assigned once in the constructor.
    It would seem to me the logical answer here is no; the VM would enforce a memory barrier between unassigned variables turning into assigned variables, but I'm just making sure, since what I've found doesn't really clarify this for me.

    Just out of curiosity, suppose the field was
    non-final. Would volatile still not be needed?If the value never changes, and if you don't let a reference leak out of the constructor, then I'm not sure if you'd need volatile.
    In general, it's possible for one thread to set a value, and another thread to never see it, if there's no syncing and no volatile. I thought that something in the new JMM prevented that in this particular case--i.e., a constructor, but I'm not sure if that's true, or what the details are.
    The answer should be here: http://java.sun.com/docs/books/jls/third_edition/html/memory.html#17.4

  • Volatile users and Groupwise settings

    OES2, Groupwise 7.1. Win XP on the workstations.
    We're starting to use a volatile user policy on a few of our computers and have run into a snag. I need to turn off Integrations under the Documents Setup in Options.
    Since the policy is creating new profiles all the time, Groupwise doesn't retain this setting. I've looked at the Client settings under C1 and don't see anything that can help.
    Anyone know of a network side setting for Groupwise changes?
    Thanks,
    Sam

    SS ISAdmin wrote:
    > Ok, I placed an SR on this and found that the reg key is located in
    > HKCU\Software\Novell\Groupwise\Client\Library.
    > There are a host of other options in the Client folder but since it is
    > the Current_User segment, it'll be different for each user.
    > Since this a 24 hour volatile user, and the user profiles are created
    > every day, I had to find a way to make the Reg changes happen for all
    > users regardless of whether they'd logged in before.
    > Ended up exporting the relevant keys and making a batch file to run on
    > startup for all users.
    > Works so far...
    >
    >
    I don't do volatile profiles, but can't you assign it to Default User
    and have stuff be merged in?

  • Volatile Images vs Normal Image

    I am working a tile-based game, so reducing the time required to draw a tile would be a big help. I know that if you use volatile images (Java's term for images stored in video memory) you get better performance. However, I read that Java does this in the background where possible and that in most cases manually coding the use of volatile images (including checking that they have not been dumped from video memory) is a waste of time because the standard Image class handles this for you. Is this correct?
    Currently my game uses standard images. During the first few redraws of the screen (it is turn-based, not real-time) the delay is very noticable, but after that silky smooth. I'm wondering if that is the JRE reaching some threshold and switching to volatile image use. Any ideas? (I realize it could be a hot spot compiler kicking in, but it seems unlikely that 2-3 calls of the paint function are sufficient to result in a hot spot compilation.)

    yep,
    this is the Thread you are after :-
    http://www.javagaming.org/cgi-bin/JGNetForums/YaBB.cgi?board=2D;action=display;num=1048663269;start=0#0
    More specifically this bit :-
    >
    3. Changing acceleration threshold
    Acceleration threshold controls how many copies from managed images
    will occur before we create a vram version of the image.
    If the number is '0', the accelerated surface is created during
    image initialization.
    The default threshold is 1.
    A new threshold can be set via flag:
    -Dsun.java2d.accthreshold=N (where N>=0)
    If the threshold is set to 0, all the vram surfaces
    for all managed images will be created at the image
    creation time, and updated during the first copy from image.
    This flag can be used to eliminate the initial delay in rendering
    when the images are being copied to the vram after the first few
    copies. Instead, the delay is effectively shifted to the image
    creation time.
    This could be useful behavior when you know that your application
    will be able to take advantage of image management; just get the
    overhead of the copy over with at the start instead of incurring some
    number of slower copies to begin with and then having the copy overhead
    at some later time.
    System.setProperty("sun.java2d.accthreshold", "0");

  • Volatile vs synchronized

    Does anyone have any opinions or references on the performance advantage (or disadvantage) of using a volatile variable as opposed to synchronizing on some object to reference it?

    Here's a little code snippet I dreamed up and the results
    public class Test {
         static volatile int thisInt = 0;
         static int thatInt = 0;
         static int theirInt = 0;
         public static void testVolatile() {
              long startTime = System.currentTimeMillis();
              for (int i = 0; i < 100000000; i++)
                   thisInt = i;
              long stopTime = System.currentTimeMillis();
              System.out.println("Total time for volatile: " + (stopTime - startTime));
         public static synchronized void testSynchronized() {
              long startTime = System.currentTimeMillis();
              for (int i = 0; i < 100000000; i++)
                   thatInt = i;
              long stopTime = System.currentTimeMillis();
              System.out.println("Total time for synchronized: " + (stopTime - startTime));
         public static void testFineSynchronized() {
              long startTime = System.currentTimeMillis();
              for (int i = 0; i < 100000000; i++) {
                   synchronized (Test.class) {
                        theirInt = i;
              long stopTime = System.currentTimeMillis();
              System.out.println("Total time for fine synchronized: " + (stopTime - startTime));
         public static void main(String args[]) {
              Test.testVolatile();
              Test.testSynchronized();
              Test.testFineSynchronized();
    }java version "1.3.1"
    Java(TM) 2 Runtime Environment, Standard Edition (build 1.3.1-b24)
    Java HotSpot(TM) Client VM (build 1.3.1-b24, mixed mode)
    The computer is a single processor PII 400Mhz
    Total time for volatile: 1332
    Total time for synchronized: 1572
    Total time for fine synchronized: 95107

  • Reading HashMap Values From a File

    Hi,
    I haven't done file I/O in quite a while, so I'm a little rusty.
    I have a HashMap<TreePath, Entity> that I need to store persistently. Thus far I have been creating a new HashMap every time a new session starts and populating it with Entity objects that I create from JDBC ResultSets. The TreePath is generated by adding each Entity object to its parent in the JTree. That all works well.
    Now I'm trying to write the HashMap to file using ObjectOutputStream. Basically I want to be able to load the JTree (which does not need to be persistent at this stage), and as I load it I get the TreePath of each TreeNode. If that TreePath is a key in the persistent HashMap, then I want to display the details stored in the corresponding Entity. However, when I try to read the HashMap using an ObjectInputStream, I get a NullPointer.
    I'm not sure whether the problem is in the way I'm trying to write or read the HashMap, or both. I've followed the examples in the API but they don't seem to be doing the job.
    Any suggestions?

    I have isolated the problem.
    HashMap<TreePath, Entity> map = memory.getMap();
    TreePath nodePath = new TreePath(node.getPath()); //where node is a DefaultMutableTreeNode
    System.out.println("1. Desired key is: " + nodePath);
    System.out.println("2. Map contains key: " + map.containsKey(nodePath));
    System.out.println("3. Keys in map: " + map.keySet().toString());When I use a volatile Java object to store the map, an example of the output produced by the following code is:
    1. Desired key is: [DW, Acct]
    2. Map contains key: true
    3. Keys in map: [[DW], [DW, Acct]]
    However, when I use file I/O to make the Java object permanent, an example of the output produced by the following code is:
    1. Desired key is: [DW, Acct]
    2. Map contains key: false
    3. Keys in map: [[DW], [DW, Acct]]
    As far as I can see, line 2 of the I/O output should be true, not false, since line 3 shows that the key is present in the map.
    Am I missing something here, or is the containsKey() method returning the incorrect result? It looks like it is getting its reference to map all wrong.

  • The Group Policy Client Service Failed The Logon

    Hello,
    When our students login to our Windows 7 machines they are getting this error:
    The Group Policy Client Service Failed The Logon
    Access is denied.
    We are attempting to use both volatile and roaming profiles. The profiles are being stored on their H drives. I seem to only see the issue when the Windows NT 6.1 Workstation Profile.V2 folder already exists on their H drive. If the profile is not there then everything works fine.
    Loading the user's ntuser.dat hive located in their H drive and changing the permissions manually to allow System, Administrators, and Users Full Control fixes the issue. How can I do this across all my user's H drives? Should I just delete them all and manually create the folder myself?
    Last time I found one, the permissions for the hive had an "Unknown" user in the permissions list. There was no "Users" group. Removing the "Unknown" and adding "Users" fixed the problem. Are the permissions getting corrupted somehow?
    Thanks for any assistance.
    I've used the following link for reference:
    Support | Windows 7 Roaming Profiles fail - user is assigned a temporary profile or fails to log on
    Novell Doc: ZENworks 10 Configuration Management Policy Management Reference - Assigning a Roaming Profile Policy that has the User Profile Stored on a Home Directory

    Originally Posted by coreyhansen
    So it appears that I am experiencing the temporary profile detailed in my link I referenced above. I have status bubbles disabled by policy and didn't notice the notification. I'm going to try pre-populating my user H drives with the Windows NT 6.1 Workstation Profile.V2 folder containing an ntuser.dat file I've already edited the hive permissions of. This worked in small scale testing, so we will see.
    I've been referencing this thread: http://forums.novell.com/novell-prod....html#poststop
    So I have tried this with students that are experiencing the problem, and gotten limited success. It feels like it works at random, with around 50% of attempts working.
    Has anyone out there had success with roaming profiles? Do I just need to go back to folder redirection? Will anyone please respond?
    This is what the student's ntuser.dat hive permissions look like when things are not working:

  • Double Factory pattern purposal as replacement for Double Check #2

    Hi All,
    Here is the code for the pattern proposal, its intended as a replacement for double checked locking, which was proved to be broken in 2001. Here is the code...
    public class DoubleFactory {
       private static Object second_reference = null;
       public static Object getInstance() {
          Object toRet = second_reference;
             if (toRet == null) {
                second_reference = CreationFactory.createInstance();
                toRet = second_reference;
          return toRet;
       private DoubleFactory() {}
    public class CreationFactory {
       private static Object instance = null;
       public static synchronized Object createInstance() {
          if (instance == null) {
             instance = new Object();
          return instance;
      }Also I have spent several months discussing this with Peter Haggar, who believes that this code is not guaranteed to work. However I have been unable to discern from his message why he believes this will not be guaranteed to work, and I am posting this here to attempt to find a clearer explanation or confirmation that the pattern I am purposing (Double Factory) is guaranteed to work.
    Thanks,
    Scott
    ---------------------------- Original Message ----------------------------
    Subject: Re: [Fwd: Double Factory replacement for Double Check #2] From:
    "Scott Morgan" <[email protected]>
    Date: Fri, January 25, 2008 10:36 pm
    To: "Peter Haggar" <[email protected]>
    Hi Peter,
    I appologize if my last response came accross as rude or something. If
    my code is not guaranteed to work ok, can you help me understand why. I
    am after all looking for a solution for all of us.
    If my solution is wrong as you say because the member variables of the
    singleton are not up to date. I understand this to mean that the
    second_reference pointer is assigned to the memory where the instance
    object will get created before the instance object even starts the
    creation process (when the jvm allocates memory and then enters the
    constructor method of the Singleton). This doesn't seem possible to me.
    Can you refrase your statments, to help me understand your points?
    If not I am happy to turn to the original wiki for discussion.
    Thanks for your effort,
    Scott
    Thanks for asking my opinion, many times, then telling me I'm
    wrong...wonderful. You are a piece of work my friend. For what it'sworth, your email below shows you still don't understand these issues
    or what I was saying in my emails. I've been more than patient.
    >
    All the best. And by the way, your code is not guaranteed to work. It's not just me that's "wrong", it's also the engineers at Sun who
    designed Java, the JVM, and the memory model, and countless people who
    have studied it. I'm glad you have it all figured out.
    >
    Peter
    "Scott Morgan" <[email protected]>
    01/18/2008 12:47 PM
    Please respond to
    [email protected]
    To
    Peter Haggar/Raleigh/IBM@IBMUS
    cc
    Subject
    Re: [Fwd: Double Factory replacement for Double Check #2]
    Hi Peter,
    Thanks I understand your position now. However am I still believe that
    it will work and be safe;
    1) the Singleton you show would be fully constructed (having exited theSingleton() method) before the createInstance() method would have
    returned.
    2) The second_reference could not be assigned until the createInstance()
    method returns.
    3) So by the time second_reference points to Singleton all of the valueswill be set.
    >
    >
    I do understand that if the createInstance method was not synchronized(at the CreationFactory class level) that my logic would be flawed, but
    since there is synchronization on that method these points are true, and
    your comments about up-to-date values are not accurate.
    >
    Cheers,
    Scott
    >In your listing from your latest email T2 does encounter a sync block
    on createInstance.
    >>>>
    No. T2 will call getInstance and see second_reference as non-null.second_reference was made non-null by T1.
    >>
    >>>>
    What are you exactly are you refering to with the phrase 'up-to-datevalues'?
    >>>>
    Assume my singleton ctor is thus:
    public class Singleton
    private int i;
    private long l;
    private String str;
    public Singleton()
    i = 5;
    l = 10;
    str = "Hello";
    T2 will get a reference to the Singleton object. However, because youaccess second_reference without synchronization it may not see i as 5,
    l as 10 and str as "Hello". It may see any of them as 0 or null. This
    is not the out of order write problem, but is a general visibility
    problem because you are accessing a variable without proper
    synchronization.
    >>
    Peter
    "Scott Morgan" <[email protected]>
    01/16/2008 11:38 PM
    Please respond to
    [email protected]
    To
    Peter Haggar/Raleigh/IBM@IBMUS
    cc
    Subject
    Re: [Fwd: Double Factory replacement for Double Check #2]
    Hi Peter,
    In your listing from your latest email T2 does encounter a sync blockon createInstance.
    >>
    What are you exactly are you refering to with the phrase 'up-to-datevalues'?
    In this code the Singleton should also be
    A) non mutable (as in the instance of class Object in the example).
    If the singleton was more complex then the code to populate it'svalues
    would go inside the sync of createInstance().
    B) mutable with synchronization on it's mutator methods.
    In your article you mention out of order writes, which doesn't occurin
    this code.
    Cheers,
    Scott
    You read it wrong.
    - T1 calls getInstance which in turn calls createInstance.
    - T1 constructs the singleton in createInstance and returns to
    getInstance.
    - T1 sets second_reference to the singleton returned in getInstance. -T1 goes about its business.
    - T2 calls createInstance.
    - T2 sees second_reference as non-null and returns it
    - Since T2 accessed second_reference without sync, there is noguarantee
    that T2 will see the up-to-date values for what this object refers to.
    - Therefore the code is not guaranteed to work.
    >>>
    If this is not clear:
    - Re-read my email below
    - Re-read my article
    - If still not clear, google on Double Checked Locking and readanything
    from Brian Goetz or Bill Pugh.
    Peter
    "Scott Morgan" <[email protected]>
    01/13/2008 05:26 AM
    Please respond to
    [email protected]
    To
    Peter Haggar/Raleigh/IBM@IBMUS
    cc
    Subject
    Re: [Fwd: Double Factory replacement for Double Check #2]
    Hi Peter,
    Thanks for the reply, I don't see how T2 would see the a referenceto
    a
    partialy initialized object before the createInstance() method had
    returned. If T1 was in createInstance() when T2 entered
    getInstance(), T2 would wait on the CreationFactory's class monitor to
    wait to enter createInstance().
    Or in other words in the line of code ....
    second_reference = CreationFactory.createInstance();
    The pointer second_reference couldn't be assigned to the singleton
    instance when the synchronized createInstance() had fully constructed,initialized and returned the singleton instance. Before that the the
    second_reference pointer would always be assigned to null. So any
    thread entering getInstance() before createInstance() had returned
    (for the first time) would wait on the CreationFactory's class monitor
    and enter the createInstance() method.
    >>>
    So T2 will wait for T1.
    Cheers,
    Scott
    PS I think I am writing requirements for my next project :)
    Sorry for the delay...been in all day meetings this week.
    You are correct...I had been reading your code wrong, my apologies.
    My explanations, although correct, did not exactly correspond to your
    code.
    However, the code is still not guaranteed to work. Here's why:
    Assume T1 calls getInstance() which calls createInstance() and returnsthe
    singelton. It then sets second_reference to refer to that singleton.
    So
    far, so good. Now, T2 executes and calls getInstance(). It can see
    second_reference as non-null, so it simply returns it. But, there
    was
    no
    synchronization in T2's code path. So there's no guarantee that even
    if
    T2 sees an up-to-date value for the reference, that it will seeup-to-date
    values for anything else, ie what the object refers to...it's
    instance data. If T2 used synchronization, it would ensure that it
    read
    up-to-date
    values when it obtained the lock. Because it didn't, it could see
    stale
    values for the object's fields, which means it could see a partially
    constructed object.
    >>>>
    In the typical double-checked locking, the mistake is to assume theworst
    case is that two threads could race to initialize the object. But
    the worst case is actually far worse -- that a thread uses an object
    which
    it
    believes to be "fully baked" but which is in fact not.
    Peter
    "Scott Morgan" <[email protected]>
    01/03/2008 06:33 PM
    Please respond to
    [email protected]
    To
    Peter Haggar/Raleigh/IBM@IBMUS
    cc
    Subject
    Re: [Fwd: Double Factory replacement for Double Check #2]
    Hi Peter,
    Thanks for responding, I am still thinking that your mis
    interpreting
    the code so I have rewritten it here (Replacing
    DoubleFactory.instance with DoubleFactory.second_reference for
    clarity). If the T1 burps (gets interrupted) in the createInstance
    method it wouldn't have returned so the second_reference pointer
    would have never been
    assigned
    so T2 would just try again upon entering the getInstance method. Orif
    it had already entered getInstance it would be waiting to enter
    (until T1 releases the lock on CreationFactory.class ) on the
    createInstance method.
    >>>>
    public class DoubleFactory {
    private static Object second_reference = null;
    public static Object getInstance() {
    Object toRet = second_reference;
    if (toRet == null) {
    second_reference =
    CreationFactory.createInstance();
    toRet = second_reference;
    return toRet;
    private DoubleFactory() {}
    public class CreationFactory {
    private static Object instance = null;
    public static synchronized Object createInstance() {
    if (instance == null) {
    instance = new Object();
    return instance;
    Does this clear up my idea at all?
    second_reference should be always pointing to
    null
    or
    a fully initialized Object
    (also referenced by the pointer named 'instance' ), I don't see howit would end up partially initialized.
    >>>>
    Thanks Again,
    Scott
    "It" refers to T2.
    Your createInstance method is identical to my Listing 2 and is fine
    and
    will work.
    Yes, the problem with your code is in getInstance.
    >I don't see how the DoubleFactory getInstance method could bereturning
    a partially initialized object at this point. If CreationFactoryalways
    returns a fully initialized object and DoubleFactory only assigns a
    new
    reference/pointer to it how could DoubleFactory getInstance return a
    reference/pointer to partially initialized object?
    >>>>>>>
    >>>>>
    The reason it is not guaranteed to work is explained in my previousemails
    and in detail in the article. However, I'll try again. Anytime you
    access shared variables from multiple threads without proper
    synchronization, your code is not guaranteed to work. Threads are
    allowed
    to keep private working memory separate from main memory. There are
    2
    distinct points where private working memory is reconciled with main
    memory:
    - When using a synchronized method or block - on acquisition of thelock
    and when it is released.
    - If the variable is declared volatile - on each read or write of
    that
    volatile variable. (Note, this was broken in pre 1.5 JVMs which isthe
    reason for the caveat I previously mentioned)
    Your createInstance method uses synchronization, therefore, the
    reconciliation happens on lock acquisition and lock release. T1 can
    acquire the lock in createInstance, make some updates (ie create an
    object, run it's ctor etc), but then get interrupted before exiting
    createInstance and therefore before releasing the lock. Therefore,
    T1
    has
    not released the lock and reconciled its private working memory withmain
    memory. Therefore, you have ZERO guarantee about the state of mainmemory
    from another threads perspective. Now, T2 comes along and accesses
    "instance" from main memory in your getInstance method. What will
    T2
    see?
    Since it is not properly synchronized, you cannot guarantee that T2sees
    the values that T1 is working with since T1 may not have completely
    flushed its private working memory back to main memory. Maybe it
    did completely flush it, maybe it didn't. Since T1 still hold the
    lock,
    you
    cannot guarantee what has transpired. Maybe your JVM is not usingprivate
    working memory. However, maybe the JVM your code runs on does or
    will
    some day.
    Bottom line: Your code is not properly synchronized and is notguaranteed
    to work. I hope this helps.
    Peter
    "Scott Morgan" <[email protected]>
    01/03/2008 12:49 PM
    Please respond to
    [email protected]
    To
    Peter Haggar/Raleigh/IBM@IBMUS
    cc
    Subject
    Re: [Fwd: Double Factory replacement for Double Check #2]
    Hi Peter,
    Thanks for your response, I don't follow what 'it' refers to in
    the
    phrase 'It can see'. So for the same reason that you state that
    example 2 from your article I believe this class CreationFactory to
    work flawlessly when a client object calls the createInstance
    method.
    >>>>>
    I see this CreationFactory code as identical to your example 2 doyou agree with this?
    >>>>>
    public class CreationFactory {
    private static Object instance = null;
    public static synchronized Object createInstance() {
    if (instance == null) {
    instance = new Object();
    return instance;
    }Then my rational in the DoubleFactory class is that it can obtain a
    reference/pointer to the fully initialized object returned bycalling the above code. I believe you think that the problem with
    my code is
    in
    the DoubleFactorys getInstance method, is this correct?
    I don't see how the DoubleFactory getInstance method could bereturning
    a partially initialized object at this point. If CreationFactory
    always
    returns a fully initialized object and DoubleFactory only assigns a
    new
    reference/pointer to it how could DoubleFactory getInstance return a
    reference/pointer to partially initialized object?
    >>>>>
    Thanks again,
    Scott
    public static synchronized Singleton getInstance() //0
    if (instance == null) //1
    instance = new Singleton(); //2
    return instance; //3
    This above code is fine and will work flawlessly.
    Annotating my paragraph:
    T1 calls getInstance() and obtains the class lock at //0. T1 "sees"
    instance as null at //1 and therefore executes: instance = new
    Singleton() at //2. Now, instance = new Singleton() is made up of
    several lines of non-atomic code. Therefore, T1 could be
    interrupted
    after Singleton is created but before Singleton's ctor isrun...somewhere
    before all of //2 completes. T1 could also be interrupted after
    //2 completes, but before exiting the method at //3. Since T1 has
    not
    exited
    its synchronized block it has not flushed its cache. Now assume T2
    then
    calls getInstance().
    All still true to this point. However, with your code the nextparagraph
    is possible, with the code above, it's not. The reason is that T2
    would
    never enter getInstance() above at //0 because T1 holds the lock. T2will
    block until T1 exits and flushes it's cache. Therefore, the code
    above
    is
    properly thread safe.
    It can "see" instance to be non-null and thus
    return it. It will return a valid object, but one in which its ctor
    has
    not yet run or an object whose
    values have not all been fully flushed since T1 has not exited itssync
    block.
    "Scott Morgan" <[email protected]>
    01/02/2008 06:10 PM
    Please respond to
    [email protected]
    To
    Peter Haggar/Raleigh/IBM@IBMUS
    cc
    Subject
    Re: [Fwd: Double Factory replacement for Double Check #2]
    Hi Peter,
    Thanks for the response I understand the rational for inventing
    the
    double check anti pattern, I am sorry I still don't understand the
    difference between your solution #2 and my CreationFactory class.
    >>>>>>
    From your article figure 2.public static synchronized Singleton getInstance() //0
    if (instance == null) //1
    instance = new Singleton(); //2
    return instance; //3
    If I understand your email correctly this figure 2 is also flawed,since...
    >>>>>>
    T1 calls getInstance() and obtains the class lock at //0. T1 "sees"
    instance as null at //1 and therefore executes: instance = new
    Singleton() at //2. Now, instance = new Singleton() is made up ofseveral lines of non-atomic code. Therefore, T1 could be
    interrupted
    after Singleton is created but before Singleton's ctor isrun...somewhere
    before all of //2 completes. T1 could also be interrupted after
    //2 completes, but before exiting the method at //3. Since T1 has
    not
    exited
    its synchronized block it has not flushed its cache. Now assume T2
    then
    calls getInstance(). It can "see" instance to be non-null and thus
    return it. It will return a valid object, but one in which its
    ctor
    has
    not yet run or an object whose
    values have not all been fully flushed since T1 has not exited itssync
    block.
    So is #2 is also flawed for this reason?
    If so please revise your article, since I interpreted #2 as a
    plausible
    solution recommended by you (which lead me to the DoubleFactory
    idea).
    If not please help me understand the difference between #2 and my
    CreationFactory class.
    >>>>>>
    Thanks,
    Scott
    #2 is in Listing 2 in the article. What I meant was to forget the
    DCL
    idiom, and just synchronize the method...that's what listing 2
    shows.
    DCL
    was invented to attempt to get rid of the synchronization for 99.9%
    of
    the
    accesses.
    The solution I outlined in my email is using the DCL idiom, but on
    a
    1.5
    or later JVM and using volatile.
    You solution is not guaranteed to work. Here's why:
    public class DoubleFactory {
    private static Object instance = null;
    public static Object getInstance() {
    Object toRet = instance;
    if (toRet == null) {
    instance =
    CreationFactory.createInstance();
    toRet = instance;
    return toRet;
    private DoubleFactory() {}
    public class CreationFactory {
    private static Object instance = null;
    public static synchronized ObjectcreateInstance()
    //1
    if (instance == null) {
    instance = new Object(); //2
    return instance;
    } //3
    }T1 calls createInstance() and obtains the class lock at //1. T1"sees"
    instance as null and therefore executes: instance = new Object() at//2.
    Now, instance = new Object() is made up of several lines of
    non-atomic
    code. Therefore, T1 could be interrupted after Object is created
    but
    before Object's ctor is run...somewhere before all of //2
    completes.
    T1
    could also be interrupted after //2 completes, but before exiting
    the
    method at //3. Since T1 has not exited its synchronized block ithas
    not
    flushed its cache. Now assume T2 then calls getInstance(). It can"see"
    instance to be non-null and thus return it. It will return a
    valid object, but one in which its ctor has not yet run or an
    object
    whose
    values have not all been fully flushed since T1 has not exited itssync
    block.
    The bottom line is that if you are accessing shared variables
    between
    multiple threads without proper protection, you are open for aproblem.
    Proper protection is defined as: proper synchronization pre 1.5,
    and
    proper synchronization or proper use of volatile 1.5 or after.
    Therefore, if you must use the DCL idiom you have one option: -
    Use DCL with volatile on a 1.5 or later JVM.
    >>>>>>>
    You can also forget about DCL and just use synchronization (listing2
    in
    my article) or use a static field (listing 10 in my article).
    I hope this clears it up.
    Peter
    "Scott Morgan" <[email protected]>
    01/02/2008 04:00 PM
    Please respond to
    [email protected]
    To
    Peter Haggar/Raleigh/IBM@IBMUS
    cc
    Subject
    Re: [Fwd: Double Factory replacement for Double Check #2]
    Hi Peter,
    I apologies for not understanding but I don't see what is
    different
    between the solution you purposed...
    2) Don't use DCL but use synchronization
    and the code that I am putting forward. Perhaps I do just notunderstand
    but you seem to be contradicting yourself in this email?
    I understand that you are saying in #2 that this will always 'work'
    with
    out any issues...
    public static Object instance = null;
    public static synchronized Object getInstance() {
    if (instance == null) {
    instance = new Object();
    return instance;
    But first you seem to say in the email that if T1 gets
    interrupted
    it
    may leave the instance pointing to a partially initialized object?
    So as far as I understand it the createInstance method in my
    CreationFactory class should be successful (always retuning a
    fully initialized object) for the same reason #2 is successful.
    Please keep in mind that there are two different instancepointers
    in
    the code I sent you, one is part of the DoubleFactory class and
    the other is part of the CreationFactory class.
    >>>>>>>
    Thanks for your time, just looking for better solutions!
    Scott
    Scott,
    Your solution is not guaranteed to work for various reasons
    outlined
    in
    the article. For example, you can still return from your code apartially
    initialized object. This can occur if T1 gets interrupted beforeleaving
    the synchronized method createInstance() and T2 calls
    getInstance().
    T2
    can "see" toRet/instance as non-null but partially initialized
    since
    T1
    has not fully flushed its values.
    As of 1.5, Sun fixed various issues with the memory model that
    were
    broken. Double Checked Locking will still break unless you usevolatile
    (which was fixed in 1.5). Therefore, the following code works:
    volatile Helper helper;
    Helper getHelper() {
    if (helper == null)
    synchronized(this) {
    if (helper == null)
    helper = new Helper();
    return helper;
    but the original DCL idiom will not work. So, your options are:
    1) Use DCL with volatile (above)
    2) Don't use DCL but use synchronization
    3) Don't use DCL, but use a static field.
    #2 and #3 are outlined in my article from 2002.
    Hope this helps,
    Peter
    "Scott Morgan" <[email protected]>
    12/26/2007 04:12 PM
    Please respond to
    [email protected]
    To
    Peter Haggar/Raleigh/IBM@IBMUS
    cc
    Subject
    [Fwd: Double Factory replacement for Double Check #2]
    Hi Peter,
    Thanks for the article on the out of order write problem. Whatdo
    you
    think of this as a solution?
    TIA,
    Scott
    ---------------------------- Original Message----------------------------
    Subject: Double Factory replacement for Double Check #2
    From: "Scott Morgan" <[email protected]>
    Date: Wed, December 26, 2007 2:55 pm
    To: [email protected]
    Hi Ward,
    Here is a pattern submission
    Double Factory
    Lazy initialization of singletons in accepted for a while usingthe
    double check pattern. However it has been discovered that the
    double
    check pattern isn't thread safe because of the out of order write
    problem. This problem occurs when Threads entering the Singleton
    Factory method return with a fully constructed, but partially
    initialized, Singleton object.
    >>>>>>>>
    Therefore: It makes sense to look for a way to initializeSingletons
    in
    a Lazy and Thread Safe manor. The following illustrates a fairly
    simple
    solution...
    package foo;
    public class DoubleFactory {
    private static Object instance = null;
    public static Object getInstance() {
    Object toRet = instance;
    if (toRet == null) {
    instance =
    CreationFactory.createInstance();
    toRet = instance;
    return toRet;
    private DoubleFactory() {}
    public class CreationFactory {
    private static Object instance = null;
    public static synchronized ObjectcreateInstance()
    if (instance == null) {
    instance = new Object();
    return instance;
    This gets around the out of order write problem because all
    Threads
    waiting on the CreationFactory's Class monitor will have a fully
    constructed and initialized instance when they actually exit the
    createInstance method.
    >>>>>>>>
    >>>>>>>>
    During runtime while the Singleton instance is getting created(constructed and initialized) there may be a few Threads waiting
    on
    the
    CreationFactory Class's objects monitor. After that period all
    the
    Treads
    accessing
    the Singleton will have unsynchronized reads to the instance,
    which
    will
    optimize execution.
    References:
    http://www.ibm.com/developerworks/java/library/j-dcl.html
    Copyright 2007 Adligo Inc.

    Scott-Morgan wrote:
    Hi All,
    Thanks for your comments, here are some more....
    jtahlborn you state that
    the only way to guarantee that a (non-final) reference assignment is visible across threads is through the use of volatile and synchronized,
    From the jvm spec
    http://java.sun.com/docs/books/jls/third_edition/html/memory.html
    17.4.1 Shared Variables
    Memory that can be shared between threads is called shared memory or heap memory.
    All instance fields, static fields and array elements are stored in heap memory.
    Since both the second_reference and instance fields are both static, they are shared and visible across all threads.Yes, all these things are shared across threads, however, if you keep reading, there is a notion of "correct" sharing. obviously these values may be visible, that's why double-checked locking was used for so long before people realized it was broken. it worked most of the time, except when it didn't, and that's what i'm trying to show. that the only way to correctly share state between threads is via synchronization points, the most common being volatile and synchronized (there are a couple of other less used ones which don't apply here). The articles you linked to below from ibm cover the "visibility" in great depth, this is exactly what i am referring to.
    You also state that volatile is a solution, but you seem to rebut your self in stating that the overhead for volatile is almost as great as synchronization.
    This article illustrates the solution, and also comments on the overhead of volatile.
    http://www.ibm.com/developerworks/library/j-jtp03304/
    linked from
    http://www.ibm.com/developerworks/java/library/j-dcl.html
    volatile is a solution, in that it is correct, and you avoid the appearance of synchronization each time. however, since the semantics of volatile were strengthened in the new memory model, using volatile will perform practically (if not exactly) the same as simply synchronizing each time. the article you link to says exactly this under the heading "Does this fix the double-checked locking problem?".
    Also could you be more specific about the example at the end of the jvm memory spec page, like a section number?It's the very last thing on the page, the "discussion" under 17.9, where it mentions that changes to "this.done" made by other threads may never be visible to the current thread.

Maybe you are looking for

  • Itunes won't start up on my ipad 2.  I get a spinning wheel.

    I bought an iPad 2 to use in my classroom.  Our IT guy set it up to work with our filters so I can connect the internet, but I can't get iTunes to open.  I just get the spinning gear of death!  Any help would be appreciated.  I have synced it to my c

  • Rapid battery drain over EDGE

    EDGE seems to just rip through battery on my phone. An hour and ten minutes of browsing over edge completely drains my battery. Hardly the six hours advertised. Anyone have any suggestions?

  • Vendor Return against Asset

    All SAP Gurus, We have procured material against asset (material do not have any material code as it has been procured against asset). Now we want  to return it back to the vendor. We have created the return document through MBRL. But while creating

  • JAVA Feature

    As all we know, that java create its own platform which over its underlaying h/w , s/w . That's why java offers the nature of plateform indpendency. Due to which unlike any other language like c or c++ datatype and its storage size never depends upon

  • ODI logical schema is not enabled

    Hi, I am beginner to use ODI. What I did so far: - I created a project - Model created as follows:      - source          - Oracle          - Firebird          - File    - destination         - Oracle When I was in the source model Oracle folder (cre