Question on synchronized method / block and Thread Cache

Hi all,
I came across a blog post at http://thejavacodemonkey.blogspot.com/2007/08/making-your-java-class-thread-safe.html which is talking about making Java classes thread safe. But, I was surprised to see that a thread can have my class' instance variable in its cache. Also, I have couple of questions on the things posted in the blog. I want to get the opinion from Java experts here.
1. Given the example class
class MyClass{
     private int x;
     public synchronized void setX(int X) { this.x = x; }
     public synchronized int getX() { return this.x; }
Having the following instructions in two threads won't guarantee that it will print 1 and 2 as other thread can get the slot and call setX to modify the value - Am I right?
obj is an MyClass Instance available to both the threads
Thread 1:
obj.setX(1);
System.out.println(obj.getX());
Thread 2:
obj.setX(2);
System.out.println(obj.getX());
It will print 1 and 2 (in any order) only if I synchronize these calls on "obj" as follows - Is my understanding correct or ???
Thread 1:
synchronized(obj)
obj.setX(1);
System.out.println(obj.getX());
Thread 2:
synchronized(obj)
obj.setX(2);
System.out.println(obj.getX());
2. If my understanding on point 1 (given above) is right, What the blog-post says is wrong as I cannot even expect my thread 1 to print 1 and thread 2 to print 2. Then, again a question arises as why a thread cache has a object's instance variable value in its cache and need to make my instance variable volatile. Can anyone explain me in detail? Won't the thread always refer the heap for Object's instance variable value?
Thanks in advance,
With regards,
R Kaja Mohideen

your basic understanding (as far as i can understand what you've written) seems to be correct. if you run your first 2 threads, you can get "11", "12", "21", or "22" (ignoring newlines). if you run your second 2 threads, you can get "12" or "21".
i'm not sure i follow your second point about your thread's "cache". i think you are asking about the visibility of changes between threads, and, no, there is not concept of a shared "heap" in the memory model. basically, (conceptually) each thread has its own working memory, and it only shares updates to that memory when it has to (i.e. when a synchronization point is encountered, e.g. synchronized, volatile, etc). if every thread was forced to work out of a shared "heap", java on multi-core systems would be fairly useless.

Similar Messages

  • Performance question on looping thrue blocks and items (forms 10.1.2.3)

    Hi all,
    I'm back again in Forms forum : ) !!! and I'm working on a new and very interesting project
    version used : Forms [32 bits] Version 10.1.2.3.0 (Production)
    A little question for gurus :
    On former projects I used to call loops on blocks and item like shown below to do various things such as displaying buttons or showing canvas or different VA depending on the user or scenarios .
    PROCEDURE FRM_BLK_ITM_LOOP IS
    v_curblk varchar2(90); -- bloc courant
    v_curitm varchar2(90); -- item courant
    BEGIN
      v_curblk := get_form_property(:SYSTEM.CURRENT_FORM,first_block); -- on récupère le 1er block de la form
      LOOP
      v_curitm := v_curblk||'.'||get_block_property(v_curblk,first_item); -- on récupère le 1er item du block
        WHILE v_curitm != v_curblk||'.'||get_block_property(v_curblk,last_item)
         LOOP -- tant que l'item n'est pas le dernier du block on loop
            v_curitm :=  v_curblk||'.'||get_item_property(v_curitm,nextitem); -- on récupère l item suivant
            if get_item_property(v_curitm,<some property>) = 'TRUE' then
              --- I can do something.... or adding more conditions if then etc...
            end if;
        END LOOP;
      EXIT WHEN v_curblk = get_form_property(:SYSTEM.CURRENT_FORM,last_block); -- on sort losrqu on arrive au dernier block
      v_curblk := get_block_property(v_curblk, nextblock); -- on passe au block suivant
      END LOOP;
    END;In my current project we work on quite huge forms which can have a consequent number of blocks and items.
    And we must be very careful regarding performance issues as these forms are accessed via LAN and WAN.
    So my question :
    This method seems to be quite efficient as it goes thrue blocks and items sequences as they are defined in the builder comparing to go_block -> go_item ->do_something which can easily turn into nightmare-programming.
    But I don't really know about network roundtrips with this kind of method.
    Is everything done in the app server and then fetched to the client?
    What triggers block-level and item-level can be fired during the execution of the loop ? and so one...
    Thanks in advance for your advices on this matter.
    Jean-Yves

    Hmmm, I have to say I never bothered if Forms is in Socket mode or not; I enabled the network statistics, counted the roundtrips and looked for ways to get them lower (my old friend wireshark did also a good job regarding this) ;). But regarding the note Forms 6i uses Socket Connections by default, this might apply to 10g too (or the enhancement request was approved, who knows).
    Frankly I am not entirely sure what Socket Mode means; I guess it's the mode the forms applet talks to the forms runtime; wheter it's stateful (via Sockets) or stateless (via HTTP / HTTPS) but this is just a wild guess, and I can't find informations on it quickly. I also enabled networkStats on my Developer Suite only, so I cannot tell if you can enable them on a full-fledged Application Server.
    Anyway; as said I just counted the roundtrips and looked where I can avoid them when I made our application ready for WAN.
    Another useful tool was Shunra VE Desktop which I used to simulate low bandwith networks with high latencys; I installed it on a virtual XP, started the application and tested how the Application performs. If something looked odd, I looked behind the scenes, built a little testform basing on the code behind and tried out various things; very often you can take advantage of the event bundling forms seems to make when you use several set_xyz calls as Francois also noted; e.g.
    set_custom_property('bean_item', 1, 'PROPERTY', prop);
    set_custom_property('bean_item', 1, 'PROPERTY', prop);
    set_custom_property('bean_item', 1, 'PROPERTY', prop);
    set_custom_property('bean_item', 1, 'PROPERTY', prop);
    set_custom_property('bean_item', 1, 'PROPERTY', prop);
    vRet := get_custom_property('bean_item', 1, 'PROPERTY);most certainly will cause just 1 roundtrip; but if you use get_custom_property in the middle of the set_custom_property calls you will encounter 2 roundtrips as forms needs to synchronize (you get a value from the bean so the forms runtime needs a response) with the forms applet whereas set_custom_property is a one-way-street which can be fired off simultaneous. The same applies to fbean.invoke and fbean.invoke_bool, fbean.invoke_char and the like. Of course if you are using more then one get_custom_property in this case the roundtrips will increase accordingly.
    If you want to make use of event bundling make sure you fire off as much set_xyz as you can before forcing forms to synchronize (e.g. with get_xyz, or synchronize, create_timer,...)
    cheers

  • Differences between Synchronized methods and blocks

    Hi all,
    I would like to differences between Synchronized methods and blocks.
    - Muni

    Well, you'll get so many of right answers in next ten to thirty minutes.
    I like to yield :)
    Oooo... Ten minutes has passed.
    Synchronized block is a toilet room with a lock in a public lavatory.
    Only one person(running thread) can have the lock at a time.
    And, she/he have to receive the lock from a particular object obj like:
    synchronized(obj){.....} // one object has only one lock for this {} toilet and for any other toilets how many there are... *
    (*: In other words, while a thread is executing a synchronized(obj){} block, other threads can't enter other synchronized(obj){} blocks.)
    Synchronized method is a kind of synchronized block.
    This special block is defaulted to have lock from the object on which the method is defined.
    public class Foo{public synchronized Method(){}}
    use the lock of a Foo object.
    Message was edited by:
    hiwa
    Message was edited by:
    hiwa

  • Question about synchronizing two methods...

    i have 2 methods:
    writeData() //method 1
    createNewDataFile() //method 2
    the main thread will be using method 1 quite frequently. In method 2, a separate thread will be waking up every 10 minutes or so and doing some maintenance on the file written to in method 1. So, when the thread is in method 2 i need method 1 to standby and wait. I also want the opposite, that when the main thread is in method 2 method 1 will stand by.
    Any help is appreciated!

    799454 wrote:
    So wait,
    i thought synchronized only worked on the actual methods where it is declared:Using the synchronized keyword obtains a lock. Each object has exactly one lock associated with it. Once a thread has obtained an object's lock, no other thread can obtain that lock (and hence cannot enter a sync block on that lock) until the first thread releases it by leaving its sync block or calling wait().
    so, you're saying that if i declare:
    synchronized method 1
    synchronized method 2
    then i have a single object with 2 synchronized methods, so if thread A is in EITHER of those methods, the other method will be locked as well?The method isn't "locked" per se, but yes, 1 object, 2 synced methods, if T1 is in either method, then T2 cannot enter either method.
    I strongly urge you to go through that tutorial and/or a book on Java concurrency, thoroughly.

  • Static synchronized methods VS non-static synchronized methods ??

    what is the difference between static synchronized methods and non-static synchronized methods as far as the behavior of the threads is concerned? if a thread is in static synchronized method can another thread access simple (ie. non static) synchronized methods?

    javanewbie80 wrote:
    Great. Thanks. This whole explanation made a lot of sense to me.Cool, glad I was able to help!
    Probably I was just trying to complicate things unnecessarily.It's a classic case of complexity inversion. It seems simpler to say something like "synchronization locks the class" or "...locks the method" than to give my explanation and then extrapolate the implications. Just like the seemingly simpler, but incorrect, "Java passes objects by reference," vs. the correct "Java passes references by value," or Java's seemingly complex I/O vs. other languages' int x = readInt(); or whatever.
    In the seemingly complex case, the primitive construct is simpler, but the higher level construct requires more assembly or derivation of the primitive constructs, making that case seem more complicated.
    Okay, I just re-read that, and it seems like I'm making no sense, but I'll leave it, just in case somebody can get some meaning out of it. :-)

  • Synchronized methods trouble

    hey guys,
    I was under the impression that when u use synchronized methods, when a thread calls it any other threads calling it have to wait. If thats true then can someone help me and point out why my threads aren't waiting :(.
    import java.util.*;
    public class cannibal implements Runnable {
        private static int nonCannibal = 0;
        cannibal(){}
        public synchronized void eat(){
            boolean flag = false;
            try{
                while(nonCannibal == 0){
                    if(flag == false){
                        System.out.println("A cannibal waits in the darkness...");
                        flag = true;
                    wait();
            }catch(InterruptedException e){
                System.out.println("Some Exception!");
            nonCannibal--;
            System.out.println("Cannibal just ate someone in the woods!");
            System.out.println(nonCannibal +" survivors left!");
        public synchronized void dontEatMe(){
            nonCannibal++;
            notify();
            System.out.println("Unsuspecting person ventures to far out in the woods!");
        public synchronized void run(){
            Random generator = new Random();
            int x = generator.nextInt(2);
            if(x == 0){
                //System.out.println("Cannibal was just summoned!");
                eat();
            }else if(x == 1){
               // System.out.println("Unsuspecting Person just summoned!");
                dontEatMe();
         public static void main(String[] args) {
            Thread []x = new Thread[10];
            for(int i = 0; i < 10; i++){
                x[i] = new Thread(new cannibal());
                x.start();
    try{
    Thread.currentThread().sleep(3000);
    }catch(InterruptedException e){

    Demo:
    import java.util.Random;
    class Account {
        private int balance;
        public synchronized void deposit(int amount) {
            if (amount < 0) throw new IllegalArgumentException();
            System.out.println("increasing balance " + balance + " by " + amount);
            balance += amount;
            notifyAll();
        public synchronized void withdraw(int amount) throws InterruptedException {
            if (amount < 0) throw new IllegalArgumentException();
            while (balance < amount) {
                wait();
            System.out.println("decreasing balance " + balance + " by " + amount);
            balance -= amount;
    class Depositer implements Runnable {
        private Account account;
        public Depositer(Account account) {
            this.account = account;
        public void run() {
            try {
                Random rnd = new Random();
                for(int i=0; i<10; ++i) {
                    account.deposit(rnd.nextInt(100));
                    Thread.sleep(1000);
            } catch(InterruptedException e) {
                e.printStackTrace();
    class Withdrawer implements Runnable {
        private Account account;
        public Withdrawer(Account account) {
            this.account = account;
        public void run() {
            try {
                Random rnd = new Random();
                for(int i=0; i<10; ++i) {
                    account.withdraw(rnd.nextInt(200));
            } catch(InterruptedException e) {
                e.printStackTrace();
    class MainClass {
        public static void main(String[] args) {
            Account acct = new Account();
            Withdrawer out = new Withdrawer(acct);
            Depositer in = new Depositer(acct);
            new Thread(out).start();
            new Thread(in).start();
    }

  • MDBs and threads

    We are using Weblogic SP2 with MQ Series and MDBs. We have MDBs reading the queues
    and calling Clarify application APIs (Clarify Business Objects). Everything works
    fine on low volumes, but as the number of messages increase, weblogic stops responding
    and the beans hang. There is no error or exception!
    We have MDBS configured at 1min and 8max. Also, Java APIs have synchronized methods
    to provide thread-safe access.
    Any ideas?

    Start by taking periodic thread thumbs and go from there... Most likely
    cause is deadlock:(
    "Prashant" <[email protected]> wrote in message
    news:[email protected]..
    >
    We are using Weblogic SP2 with MQ Series and MDBs. We have MDBs readingthe queues
    and calling Clarify application APIs (Clarify Business Objects).Everything works
    fine on low volumes, but as the number of messages increase, weblogicstops responding
    and the beans hang. There is no error or exception!
    We have MDBS configured at 1min and 8max. Also, Java APIs havesynchronized methods
    to provide thread-safe access.
    Any ideas?

  • About synchronized method

    When there are codes like below...
    class A{
    synchronized calculate(){
    class B{
    public void search(){
    A a = new A();
    a.calculate(); ------- 1
    do something --------- 2
    When I call synchronized method such as number 1,
    number 2 is waiting until number 1 is finished, otherwise number 1 starts with
    another thread and number 2 is executed in regardless of number 1?
    please let me know.
    In my experience, number 2 is executed in regarldess of number 1.
    thanks in advance

    public class Syn {
    Vector test = new Vector();
    public synchronized void method1(){
    try{
    Thread.sleep(100);
    }catch(Exception e){
    System.out.println("## test =--------> "+test);
    public static void main(String[] argv){
    Syn syn = new Syn();
    SynThread thread = new SynThread(syn);
    thread.start();
    syn.method1();
    syn.test.add("jongha");
    syn.test.add("is good");
    static class SynThread extends Thread{
    Syn syn = null;
    public SynThread(Syn syn_){
    syn = syn_;
    public void run(){
    syn.method1();
    in this code, I got the result like this
    ## test =--------> []
    ## test =--------> [jongha, is good]
    when a thread is waiting for finishing synchronized method,
    that waiting thread do execute next code without waiting finishing synchronized method.
    thanks

  • Understanding asynchronous BPEL processes and threading

    Hi everybody,
    I have a question regarding asynchronous BPEL processes and threading.
    I have an asynchronous BPEL process which delivers a message (picked up from a JMS topic) to a repository (via for instance an ICAN server). This transaction must be time-sensitive, i.e. first-in is first-out.
    If I have several threads running concurrently I have no guarantee that the messages are delivered in the same order that they where generated. It seems that the suggested way around this problem is to use single-threading.
    So here's the part that I do not understand:
    An asynchronous request does not wait for a response. If I use single-threading then what happens to that single-thread if for some reason (for instance the ICAN server is not responding) the BPEL instance is dehydrated? Is the thread still allocated for waiting for the first response or does it go back and pick up the next thing on the topic? If the next thing on the topic is picked up then how can I be sure that the messages are delivered in the correct order? If the thread is still allocated to the single instance then does that not kindda go against the whole concept of an asynchronous process?
    I hope some one can explain this to me.
    Thank you in advance.
    Kind regards,
    Mathias
    PS. This question is an attempt of a different angle on another forum thread: Asynchronuos BPEL - how to get the order of messages right?

    Hi again,
    A quick follow up question:
    Is there any way to have several BPEL processes running on the same server with different settings for how many threads to use?
    It seems that the only way to set number of threads used by BPEL is to use the configuration in the BPEL console? This is an domain setting - which means that all processes deployed to the server is effected the same way?
    I am asking because I am facing a scenario where I need one BPEL process to read from a AQ queue (well actually a topic) with a single thread and another BPEL process - deployed to the same BPEL server - to read from the same AQ queue with multiple threads.
    Does anyone have any idea of how to do this? Can it be done?
    Any suggestions, hints or reference to any documentation would be very much appreciated.
    Thank you in advance,
    Aagaard

  • PS does not Provide WSDL for RTNGTYPE Synchronous Non Blocking

    Hi,
    This particular field has 5 Translate values. Of which PS does not provide an example/entry for RTNGTYPE Synchronous Non Blocking Routing in either FSCM or CRM Demo Database.
    Would like to know, if some one has created a Routing Type of Synchronous Non Blocking and implemented that.
    The reason being, that for Service Ops with the RTNGTYPE as Synchronous Non Blocking, PS does not allow us to generate WSDLs...Also, Not sure how to create a Sync Non Blocking Routing for a Sv Op in PS...
    Any help is appreciated...
    Thanks
    Prashant

    Are you sure you have uploaded everything in the gallery folder to the correct location. It can't find the index.html page.

  • Question about "synchronized" and "wait"

    Hello, everyone!
    I have seen a piece of code like this,
    synchronized (lock)
    //do operation 1
    lock.wait();
    //do operation 2
    I think in the above piece of code, when a thead finished operation 1, it will release the lock and let other threads waiting for the lock have chance to run the same block of code. Am I correct?
    If I am correct, I have a further question, a "synchronized" block means a set of operations that can not be interrupted, but when invoke "wait" method, the thread running in the "synchronized" block will be terminated (interrupted) by release the lock and other threads will have chance to enter the "synchronized" block. In short, the execution inside the "synchronized" block will be interrupted. So, I wonder whether the above piece of code is correct and conforms to the principle of "synchronized". And what is its real use?
    Thanks in advance,
    George

    Thanks, pkwooster buddy!You're welcome
    I just wondered whether "wait inside a synchronized
    block" technology is thread safe. Please look at the
    following example,wait and synchronized are thread safe.
    public class Foo {
    int mVal= 0;
    public final Object mLock = ...;
    public void doIt() {
    synchronized(mLock) {
    mVal = ...;
    mLock.wait();
    if (mVal == ...) {
    // do something
    } else {
    // do something else
    }If we have two threads, T1 and T2, enter the block in
    their respective order, and T1 is woken up first, T2
    may have tampered with T1's execution path because T2
    changed mVal while T1 was asleep. So T2 manipulate
    instance field mVal is a side-effect.when you do the wait() you give up the lock and the other threads get a chance to run. When you exit the wait() you get the new value of the myVal variable which may have been changed. This is exactly what you want. To make that not thread save you could do
    int temp = myVal;
    wait();
    if(temp == ...)in this case the variable temp contains the old vale of myVal.
    >
    I think the most safest way is never wait inside a
    synchronized block, but it is less efficient. What do
    you think about the trick of wait inside a
    synchronized block? I think you are very experienced
    in thread field from your kind reply.
    Thanks in advance,
    Georgewait(), notify() and notifyAll() are very useful. You need them when you want threads to cooperate in an predictable manner. I recommend that you review the section on consumer and producer classes and wait and notify in the Threads Tutorial. It gives good examples. For a practical example of this you could also take a look at my Multithreaded Server Example. It implements a simple chat server that switches String messages. Look especially at the send(), doSend() and popMessage() methods in the StreamConnection class. These allow the receive thread of one user to send messages out using the send thread of another user. If you have questions about that example, please post the questions on that topic.
    Hope this helps.

  • Synchronized method's block list implementation

    In an object with synchronized methods, the OS maintains the list of blocked objects waiting to enter synchronzied methods. For this reason, I'm guesing, the Java spec seems to state the selection of these blocked objects as "arbitrary."
    I am trying to determine that there is no risk of stavation in this blocked pool of threads. For example, a FIFO implementation of the blocked-object list would guarantee that all objects eventually entered their appropriate synchronized method.
    Does anyone know for certain what blocked object selection algorithm is present on a JVM running on a Win32 platform? On SunOS 5.6? I believe the former uses a priority-based, preemptive thread scheduling with a round-robin-style time quantum to prevent starvation. Not sure what the latter uses.
    Any ideas? Thanks!
    -Jeff Ishaq

    In an object with synchronized methods, the OS
    maintains the list of blocked objects waiting to enter
    synchronzied methods. For this reason, I'm guesing,
    the Java spec seems to state the selection of these
    blocked objects as "arbitrary."
    As a general rule, you can never depend on the underlying threading model. The trend is to use the native threading model but that is not guaranteed by the specification.
    I am trying to determine that there is no risk of
    stavation in this blocked pool of threads. For
    example, a FIFO implementation of the blocked-object
    list would guarantee that all objects eventually
    entered their appropriate synchronized method.
    When a thread attempts to acquire a lock, it only checks to see if another thread already holds the lock, and not if another thread is already waiting for the lock. Therefore you should always consider the possibility that starvation can occur.
    Does anyone know for certain what blocked object
    selection algorithm is present on a JVM running on a
    Win32 platform? On SunOS 5.6? I believe the former
    uses a priority-based, preemptive thread scheduling
    with a round-robin-style time quantum to prevent
    starvation. Not sure what the latter uses.
    Again, you should avoid depending on the native threading model because the specification does not guarantee that the java threading model is going to behave the same way.
    To guarantee that each thread can acquire the lock you will need to develop a lock that has a queue associated with it. When a thread attempts to acquire the lock it is placed in a queue waiting until it is the first element in the queue. When the thread releases the lock it removes itself from the queue and notifies the other threads that are waiting.
    When using a queued lock you will not necessarily need to use the synchronized keyword on the method or block since the lock will take care of synchronization when a thread attempts to acquire the lock.

  • Need blocking method without blocking main thread

    I have this problem:
    public void blockingMethod() {
      frame.setVisible(true);
      // wait for the user to click on a button on the frame
      return;
    }I want to make a method blocking until the user press a button on the frame. However, I can't make the current thread sleep or wait and then notify it when the button is pressed, because it is the main thread that calls this method. And the main thread is responsible for listening to events and repaint the frame.
    I could solve my problem by using a modal Dialog and let the user enter some data there and then exit the Dialog. Dialog.show() would block until the user exits it again. But I would rather use my frame, so I took a look at the code for Dialog.show() method, and it does something like this:
    EventDispatchThread dispatchThread =(EventDispatchThread)Thread.currentThread();
    * pump events, filter out input events for
    * component not belong to our modal dialog.
    * we already disabled other components in native code
    * but because the event is posted from a different
    * thread so it's possible that there are some events
    * for other component already posted in the queue
    * before we decide do modal show. 
    dispatchThread.pumpEventsForHierarchy(new Conditional() {
      public boolean evaluate() {
        return keepBlocking && windowClosingException == null;
    }, this);But EventDispatchThread is package protected, so I can't do this.
    Any suggestions? I think there are circumstances where you would like a method block, but where it is the main thread that calls the method (out of my control), and you would not like the main thread block unless you could make sure the gui would still repaint and events would run.

    Ah, nm. The main thread is not the same as the event thread.
    Whew! :)
    The first who reply will get the dukes.

  • Static method and threads?

    I have a question regarding "static". for example, I have the following code
    class Test{
    public int i=0;
    public static calculateInt(){
    ....some operations on i;
    if two processes attempt to call Test.calculateInt() at the same time. What will the effects be? shall these two calls be implemented totally independent? each call holds it own "i" for calculation. OR there will be operation conflicit on i.
    what if I change "public i" to :private i", the same effects?

    You can't operate on i in a static method, since i is an instance variable.
    If you make i static, then you can operate on it in a static method. In that case, all threads will share a single i--there's only one i for the whole class, and threads don't change that. Making it private won't change that.
    If you make the method into an instance (non-static) method, then any threads operating on the same instance will share the same i, regardless of whether it's public or private. Different threads operating on different instances will each have their own i.
    Java's Thread Tutorial
    JavaWorld: Introduction to Java threads
    IBM: Introduction to Java threads
    Google: java+threads+tutorial
    Also check out http://java.sun.com/j2se/1.4.2/docs/api/java/lang/ThreadLocal.html

  • Thread caching generally and the print API specifically

    hi - new slant on the old "printing" chestnut
    code goes something like this.
    a)
    PrintService[] x = javax.print.PrintServiceLookup.lookupPrintServices(null, null);
    System.out.println (x.length)
    code end, then repeat
    b)
    PrintService[] y = javax.print.PrintServiceLookup.lookupPrintServices(null, null);
    [break point]
    PrintService[] z = javax.print.PrintServiceLookup.lookupPrintServices(null, null);
    code end
    example a)
    if i run the same piece of code twice over, deleting a printer after the first time thru, i get the right answer on the second run.
    example b)
    if i stop the code at the break point, and then delete a printer; i get the same answer for z as for y. Still using the same JVM and thread, remember.
    i think the JVM or thread is caching the answers to this static call "lookupPrintServices". so i get the same answer until the code ends and the JVM exits.
    since this is going to run in an EJ bean, a workaround might be creating a child thread, doing the printer discovery in it, then returning the answer somehow to the waiting main program. This is nasty - does anyone have an other ideas ?
    thanks

    In fact, these server process have multiple devices attached because there are different hardware requirements depending on metadata recorded in the XML file (paper size/type, duplex printing). When a new hardware requirement arises, we may need to install a different device. It may also be the case that an XML contains a new printer name but that an existing device matches the requirements. We then install a new (logical) printer and map it to the port of the existing matching device.
    Any way, the device selection is data-driven and is somewhat dynamic (we will not add printer every day/hour but it will happen and the service should preferably not be interrupted)
    The problem of a new report type with hardware requirements already supported by existing devices could be solved by a override method but the problem of new hardware specifications, requiring the installation of a new printer can currently be solved only by bouncing the VM, which must be done carefully (being sure that a report has been processed completely and that the next one has not yet been started).

Maybe you are looking for