Documenting Events and Threads

Does anyone have any thoughts on how to show multiple threads and events on
an object interaction diagram?
Specifically, the OID shows one vertical line per object, and shows a
method invocation as a horizontal connection between two objects. How do
you show event Posts and waiting for events on the diagram? and how would
you show an asynchronous call to a task?
Thanks
-Nabil
==================================================
Nabil Hijazi Optimum Solutions, Inc.
[email protected] 11654 Plaza America Drive
Phone: (703) 435-3530 #501
Fax: (703) 435-9212 Reston, Va 20190
--------------------------------------------------

Does anyone have any thoughts on how to show multiple threads and events on
an object interaction diagram?
Specifically, the OID shows one vertical line per object, and shows a
method invocation as a horizontal connection between two objects. How do
you show event Posts and waiting for events on the diagram? and how would
you show an asynchronous call to a task?
Thanks
-Nabil
==================================================
Nabil Hijazi Optimum Solutions, Inc.
[email protected] 11654 Plaza America Drive
Phone: (703) 435-3530 #501
Fax: (703) 435-9212 Reston, Va 20190
--------------------------------------------------

Similar Messages

  • Future.get and the event despatch thread blocking

    neeeyaaarghhhh
    been tying myself in knots thinking about this
    Following one of the java tech tips I've been using Callable and Future objects when I want to return a result from a task, in my case it's usually some file processing
    So I have a file chooser gui, I select a file and launch my Callable and await the result in Future.get...
    Now the problem is... Future.get I understand blocks the calling thread until the computation / work in the Callable is done and the result returned. In this case the blocked thread will be the event despatch thread... which causes problems as during my file reading I have a JProgressBar running and updating. Well at least I did, now it doesn't show up at all as all the updates to the JProgressBar via invokeLater are queued (as event despatch thread is blocked) until after the work thread has finished
    How do I launch a Callable, await the result and have some limited gui activity as the task progresses? The only solution I've found is to have the ProgressBar in a modal dialog, to block out the rest of the gui like this whilst I do the work in the event despatch thread (and drop the idea of threading altogether)
    Is my mental modal of how worker threads should spin off from the event thread flawed or am I just missing some 1 line command?

    In the situation of updating the gui, you usually want to pass some sort of callback object to the asynchronous code and have that callback method run on the gui event thread.
    public class GuiClass {
    public void handleResult(Object data);
    public void startTask() {
      threadpool.execute(new Runnable() {
        public void run() {
          // ... do asynch work ...
          final Object myResult = ...;
          SwingUtilities.invokeLater(new Runnable() {
            public void run() {
              handleResult(myResult);
    }In this code, the startTask method is called on the gui thread. it starts some async work on the threadpool. when finished, the asynch task queues the result to be handled back on the gui thread. the handleResult method is called later on the gui thread with the final result. thus, no blocking of the gui thread.
    The Callable interface is great for when the invoking thread needs to wait for a result, but you pretty much never want to do this with the gui thread.

  • Flex events, priorities and threads

    Hello,
    I have been reading from several places that flex is entirely single threaded, that two pieces of code will never be executed concurently, even when using timer events, and so on...
    On the other hand, http://livedocs.adobe.com/flex/3/html/help.html?content=events_09.html says:
    Even if you give a listener a higher priority than other listeners,
    there is no way to guarantee that the listener will finish executing
    before the next listener is called. You should ensure that listeners do
    not rely on other listeners completing execution before calling the
    next listener. It is important to understand that Flash Player does not
    necessarily wait until the first event listener finishes processing
    before proceeding with the next one.
    Could someone explain how a listener can be called "before the previous listener is finished", if the statement regarding single threading is true???
    I am running into a very nasty bug that I can't explain unless I have a race condition between two functions accessing the same ressource inside events. It is really looking like event callbacks are executed in separated treads, which would be consitent with Adobe doc about events and priorities.
    Thank you in advance for any hint...
    Pierre

    Sure it helps.  It means that a whole class of possible causes has been
    eliminated.
    Anyway, describe your problem in more detail.  Keep in mind that while you
    don't have to worry about concurrency issues, you do have to worry about
    asynchronicity issues.  Network calls, for example, are asynchronous, which
    means that they do not block the UI, and their event handlers will run
    later, when the response returns (but it won't interrupt other actionscript
    processing).  I don't believe that responses are guaranteed to return in the
    order requested and that can cause your code to run in a different order
    than expected.

  • CODE TRICK: event dispatch thread and tables

    This is a handy little trick for all you MVC users out there...
    I was working on a table class and I had this little issue that came up about not calling the AbstractTableModel's update (fireXxx()) methods from outside the event dispatch thread.
    As I'm one to create my own table models anyway, to match my data source, I found this little trick, with a little help from java.awt.EventQueue, works nicely to let the method be called from any place without having to worry about what thread it's in. Seems to work well...
         * Overridden to make safe when calling from the event dispatch thread
         * or another thread.
         * @see javax.swing.table.AbstractTableModel#fireTableRowsUpdated(int, int)
        public void fireTableRowsUpdated(final int firstRow, final int lastRow)
            if(EventQueue.isDispatchThread())
                super.fireTableRowsUpdated(firstRow, lastRow);
            else
                try
                    // could use invokeLater, depending on your needs
                    SwingUtilities.invokeAndWait(new Runnable() {
                        public void run()
                            MyTableModel.super.fireTableRowsUpdated(firstRow, lastRow);
                catch (Exception e)
                    e.printStackTrace();
        }

    http://java.sun.com/products/jfc/tsc/articles/timer/index.html

  • Applet UpCall from JS Event - Which Thread? Options

    Hi,
    With many direct references to the second lovely colour diagram on this
    page: -
    http://java.sun.com/javase/6/docs/technotes/guides/jweb/applet/applet...
    I completely understand the hour-glass pause on the single-JS-thread
    preservation architecture when the red arrow for the additional
    "applet-spawned" thread tries to call down when the applet worker thread is
    already calling down. Very clever; love it! Well done all involved.
    What I'd like to know : -
    1) When the additional applet-spawned thread calls down into Javascript and
    that JS calls setTimeout(myFunc,1000) and myFunc eventually [up]Calls back
    into the Applet, which thread will host the call to the applet method?
    Default-Worker or Applet-Spawned? Is the tenuous link/association to a
    round(ish)-trip preserved?
    2) What happens when a single JAVA thread is the target of affection from
    multiple Javascript UpCalls? (The scenario being a) an event upCalls to JAVA
    b) The Applet takes some time before returning c) The single Javascript
    thread is now free to accept further events or down-calls d) a subsequent
    event has triggered another UpCall request e) but the thread is
    busy/occupied with the first)
    I am desperately trying to pin down architected behaviour here that is the
    reciprocal of the down-call throttling. Please help if you can.
    Cheers Richard Maher

    Hi Baftos,
    Thanks for your reply and help. Yes, anecdotally, UpCalls back to the Applet are handled by the thread that called down to Javascript. (As advertised and documented in the Round-Trip scenario). And the good news is that events that call back into the Applet (regardless of provenance) are handled by the appropriate "Applet N LiveConnect Worker Thread". So if you want to callback to the Applet Worker Thread then just setTimeout(yourFunc,0) rather than just yourFunc().
    This is expected/wished-for behavior and it would be nice to see it documented somewhere? (The event-processing-thread" bit)
    Now, if someone can answer part 2 of my question then that would be magnificent!
    "> 1 Javascript UpCall" and "only one target Thread"
    Cheers Richard Maher

  • Image repaint preformance and threading

    Folks,
    I'm trying to make this sucker run faster.
    My question is, can anyone please guide me, especially with regards synchronising the Threads more efficiently... I'm thinking of using join and i]notify to make the "navigator" threads yield to the swing threads, to give it a chance to repaint before continuing... does this sound sane to you?
    Currently, without the thread.sleep it paints get the first "burst", and then nothing until the alrorithm has completed... exactly not what I wanted, because the whole point of this GUI is to watch the algorithm at work... sort of a "visual debugger"... I find that watching an algorithm play out helps me to "imagineer" ways of improving it... and in this case improvement means optimisation... it's all about getting from A-J faster than anyone else on the planet, especially those smarty-wishbone-legs C# programmers ;-)
    The code is too big to post (darn that 7500 char limit!) so I'll split it over several posts here, and I've also posted it as a single download to [MazeOfBoltonGUI2.java|http://groups.google.com/group/comp_lang_java_exchange/web/MazeOfBoltonGUI2.java] on my google group (comp lang java exchange).
    Cheers all. Keith.
    package forums.maze;
    import java.util.List;
    import java.util.ArrayList;
    import java.util.Map;
    import java.util.HashMap;
    import java.util.SortedMap;
    import java.util.TreeMap;
    import java.util.Stack;
    import java.util.Queue;
    import java.util.PriorityQueue;
    import java.util.Iterator;
    import java.util.Set;
    import java.util.concurrent.Callable;
    import java.util.concurrent.ExecutorService;
    import java.util.concurrent.Executors;
    import java.util.concurrent.Future;
    import java.util.concurrent.ExecutionException;
    import java.awt.Dimension;
    import java.awt.Color;
    import java.awt.Graphics;
    import java.awt.Graphics2D;
    import java.awt.Font;
    import java.awt.image.BufferedImage;
    import java.awt.event.ActionListener;
    import java.awt.event.ActionEvent;
    import javax.swing.JPanel;
    import javax.swing.JButton;
    import javax.swing.JFrame;
    import javax.swing.SwingUtilities;
    import javax.swing.SwingWorker;
    import java.io.PrintWriter;
    import java.io.BufferedWriter;
    import java.io.FileWriter;
    import java.io.BufferedReader;
    import java.io.FileReader;
    import java.io.IOException;
    * A Visual debugger,
    * for the [A* Alogorithm|http://en.wikipedia.org/wiki/A*_search_algorithm] navigator
    * of the [Maze Of Bolton|http://cplus.about.com/od/programmingchallenges/a/challenge12.htm]
    * as implemented by [Prometheuz|http://forums.sun.com/profile.jspa?userID=550123]
    * with GUI by [Kajbj|http://forums.sun.com/profile.jspa?userID=91610]
    * hacked together by [Keith Corlett|http://forums.sun.com/profile.jspa?userID=640846]
    * and posted on [Sun's Java Forum|http://forums.sun.com/thread.jspa?threadID=5319334]
    * and posted on [Google news group|http://groups.google.com.au/group/comp_lang_java_exchange/]
    public class MazeOfBoltonGUI2
      static final char[][] matrix = readMatrix("map.txt");
      public static void main(String[] args) {
        SwingUtilities.invokeLater(
          new Runnable() {
            public void run() {
              try {
                MazeNavigator navigator = new MazeNavigator(matrix);
                JFrame frame = new JFrame("MazeOfBoltonGUI2");
                frame.setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE);
                frame.setContentPane(new MainPanel(navigator));
                frame.pack();
                frame.setVisible(true);
              } catch (Exception e) {
                e.printStackTrace();
       * Reads the file into a char matrix[rows,cols] ie: an array of char arrays.
       * @param String filename - the name of the file to read
       * @return a fixed length array of strings containing file contents.
      private static char[][] readMatrix(String filename) {
        try {
          BufferedReader input = null;
          try {
            input = new BufferedReader(new FileReader(filename));
            char[][] matrix = null;
            List<String> lines = new ArrayList<String>();
            String line = null;
            while ( (line = input.readLine()) != null ) {
              lines.add(line);
            int rows = lines.size();
            matrix = new char[rows][];
            for (int i=0; i<rows; i++) {
              matrix[i] = lines.get(i).toCharArray();
            System.err.println("DEBUG: rows="+rows+", cols="+matrix[0].length);
            return matrix;
          } finally {
            if(input!=null)input.close();
        } catch (IOException e) {
          e.printStackTrace();
          throw new IllegalStateException("Failed to readMatrix!", e);
    class MainPanel extends JPanel
      private static final long serialVersionUID = 1L;
      // button panel
      private final JButton goButton;
      // maze panel
      private final MazeNavigator navigator;
      private final Monitor<Path> monitor;
      private BufferedImage background;
      private BufferedImage image;
      private List<Path>currentPaths;
      public MainPanel(MazeNavigator navigator) {
        this.navigator = navigator;
        this.monitor = new SwingMonitor();
        this.goButton = new JButton("Go");
        goButton.addActionListener(
          new ActionListener() {
            public void actionPerformed(ActionEvent event) {
              final String caption = goButton.getText();
              goButton.setVisible(false);
              monitor.execute();
        add(goButton);
        setPreferredSize(new Dimension(navigator.maze.cols*3, navigator.maze.rows*3)); //w,h
      public void paintComponent(Graphics g) {
        super.paintComponent(g);
        if (image==null) {
          image = (BufferedImage)createImage(navigator.maze.cols, navigator.maze.rows);
          mazeColors = createMazeColors(navigator.maze);
        this.draw(image.createGraphics());
        ((Graphics2D)g).drawImage(image, 0, 0, super.getWidth(), super.getHeight(), null);
      private static Color[][] mazeColors;
      private static Color[][] createMazeColors(Maze maze) {
        Color[][] colors = new Color[maze.rows][maze.cols];
        for (int r=0; r<maze.rows; r++) {
          for (int c=0; c<maze.cols; c++) {
            colors[r][c] = getColor(maze.matrix[r][c].ch);
        return colors;
      }*... PTO ...*

    I'm persuaded that the main issue (no intermediate results drawn) is the improper use of SwingWorker.
    When you've got over it, you may want to consider other smaller-effect optimizations:
    Reconsider usage of an offscreen image*
    public void paintComponent(Graphics g) {
        super.paintComponent(g);
        if (image==null) {
          image = (BufferedImage)createImage(navigator.maze.cols, navigator.maze.rows);
          mazeColors = createMazeColors(navigator.maze);
        this.draw(image.createGraphics());
        ((Graphics2D)g).drawImage(image, 0, 0, super.getWidth(), super.getHeight(), null);
      }At first I didn't get why you wanted to draw an offscreen image, then paint it to the screen, all that in the EDT.
    After reading the draw() method more closely, I guess you want to ease the coding of the scaling: you draw an image where one cell = one pixel, then paint the image, scaled to the panel's display size.
    In terms of performance, I don't know how it stands:
    On one hand, the image creation if lighter (1 pixel per cell). And you have a point that the built-in scaling offered by Graphics2D.drawImage(image, size) may be efficient. I can't comment on that, I hope the granphics and hardware acceleration folks will pop in the thread.
    On the other hand, if the built-in scaling had poor performance, it may be good to try what "manual" scaling would bring you. That means, in a simplified version, skip the offscreen image creation, and draw directly on the paintComponent()'s Graphics2D argument. the drawing of a cell at coordinates c,r, for example, would look like:
    g.fillRect(c*CELL_WIDTH, r*CELL_HEIGHT, WIDTH, HEIGHT);Performance apart, the scaling as you do it currently has functional drawbacks, if you want pathes as 1-pixel width lines over large cells:
    - if the maze is smaller (in rows, columns) than the panel displaying it (in pixels), the cells will be scaled but the pathes too: so your 1-pixel lines appear as large as the cells. May or may not be a desired effect.
    - if the maze is larger than the display panel, the cells are shrinked, fine, but the so are the path lines, to a point where they may be invisible (probably depending on color blending, I'm a n00b at graphics operations).
    But maybe I misunderstood the need, and maybe the intended drawing of a path is actually the drawing of the rectangles of all its traversed cells, in special path colors?
    Reconsider intermediate allocations*
    Each paintComponent() call results in the allocation of a 2D-array of Color objects (method createMazeColors(Maze)).
    I don't see what the mazeColors array brings you. I assume you wanted to decouple the determination of colors (depending on cell state) and the rendering of the colors: what does it bring: no performance advantage (on the contrary, it adds a 2D array allocation, and 2xN^2 2D-array access), and does not improve the code readability either (subjective rant, sorry).
    Why don't you pass the Maze as an argument to the draw() method, and call the getColor(cell.ch) from there?
    Side note, maybe a bit subjective: performance apart, the design of the usage of this mazeColor array is a no-go!
    An instance method alters a static variable reference,which is used subsequently in another instance method, with no synchronization. The current code does that in a single thread (+paintxxx()+ is only called in the EDT), which keeps that safe (I'd dare to say: by luck), but considerations exposed below may have you refactor the design to introduce other threads, and may exhibit the thread-unsafety of this design.
    Consider drawing the image in a background thread.*
    Indeed the technique of drawing to an offscreen image is quite common, but it is often done to improve responsiveness (not raw performance) of Swing applications. Here is a resource about this (what the author calls the passive approach), although it doesn't use a background thread.
    The idea is that if a paintCompobnent() methods involves lots of computation (arithmetics of traversing a 2D model, scaling things, etc.), this takes CPU times in the EDT, and all subsequent events (such as, a MouseEvent, but also other painting events) keep pending on the event queue, which is consumed by the single event-dispatch thread. The result is that the UI appear unresponsive, and painting of other areas may seem hung.
    The idea is to move the computation to a background thread, which posts rendering to the EDT when the Image is ready to be displayed.
    Of course this doesn't gain any CPU time. This only ensures the EDT uses a minimal part of this CPU (only render and image and process events), instead of performing the whole computation.
    In your case you already have a background thread, and indeed an appropriate choice, a SwingWorker. The application of this technique would consist in calling the draw() method in the worker thread (in the update(Path) method), and invoke super.publish() only after the image has been updated. Note that the process(List<Path>) could then ignore its argument (you may reconsider the choice of type parameter of the worker), and simply get the latest version of the image attribute).
    Of course in this technique, the offscreen image filling is called synchronously from the Navigator, so this halts the algorithm part itself, for the duration of the image generation. You may refine the technique by spawning a dedicated thread for the image generation - with subtle guard code to handle occasions when the algorithm goes faster than the image generation, and posts a new update(Path) while the image generation for the previous path has not completed yet...
    Recuce the number of things to redraw*
    Two parts:
    first, depending on the number of cells and pathes, there may be (yet another) optimization, to not redraw the whole offscreen image, but only the cells/path that have changed in the last update(). In particular, if a path is not a line but a list of cells, then it's quite easy, reusing the current offscreen image, to only fillRect(...) the appropriate cells.
    Second, if a path is not rendered as a thin line over larger cells, but as cells themselves rendered in special path colors, you may paint cells and path in one go: instead of drawing, first the cells, then the path, draw only the cells, electing the color using a decision method such as:
    private Color getColor(Cell) {
        if (cell.getPathState()!=NOT_IN_ANY_PATH) {
            return getColor(cell.getPathState());
        else {
            return getColor(cell.ch);
    }Of course this forces you to modify your data model, and update the new pathState as part of the algorithm (or better isolated, in the update(Path) method, before invoking the drawing machinery). Maybe that was the intention of the mazeColors array?
    I haven't studied your other posts on the logic of the MazeOfBolton algorithm, so I don't know if it's acceptable for you that a cell appear to have only one path state, as opposed to one for each of the pathes that traverse it. This last trick may then seem incorrect, but please consider it as only a graphical information, and indeed your current image drawing draws only ONE path for a given cell (the last path in currentPaths that traverses this cell ).

  • Not Running on the Event Dispatch thread, but UI still freezes

    The environment: I am currently working on an application that requires some heavy lifting in response to user input on a UI. To do this I am using a version of SwingWorker that was backported from java 1.6 to java 1.5 in conjunction with a slew of custom threads.
    The problem: I am currently running into an issue where I am not operating on the Event Dispatch thread (checked by doing a javax.swing.SwingUtilities.isEventDispatchThread()) but the UI is still freezing during this section. The operation involves a loop with about 2000 iterations and contains several file accesses. I have thought about how to make a new thread to perform the same operation, but I do not see how it would be any different since as it is I am not on the EDT. The call is being made from doInBackground and specifically the piece that is slowing things down is the File Accesses (2 for every iteration of the loop). At this point I am not sure how to go about resolving the issue. Any one have any suggestions?

    I am not operating on the Event Dispatch threadThat is the problem. Use multiple threads for GUI, which should delegates to the EDT, and your app logic.

  • Event Dispatch Thread Hangs, what is wrong?

    The Event Dispatch Thread Hangs when showing a modal dialog while running a
    SwingWorker Thread.
    I have included my code at the bottom of the page. There are three classes. I have posted a bug report to red hat. But I want to make sure my code is correct.
    My test case just puts the SwingWorker to sleep
    but the problem occurs if I do something real, like connect to a database, etc.
    Also I have tried little different variations of the logic calling
    setVisible(true)/(false) in different places and the same problem occurs.
    It seems to work with Sun JDK, note I am using IcedTea with Fedora Core 8.
    Version-Release number of selected component (if applicable):
    [szakrews@tuxtel ~]$ java -version
    java version "1.7.0"
    IcedTea Runtime Environment (build 1.7.0-b21)
    IcedTea Client VM (build 1.7.0-b21, mixed mode)How reproducible:
    Every couple times.
    javac TestClass2
    java TestClass2eventually it will hang. If it doesn't try again.
    You don't have to wait for the program to finish either.
    The program runs the Dialog 10 times but it never works or fails in the middle, it will either work or fail from the first dialog displayed.
    I have included a thread dump. That is about the most informative information I can get. Neither tracing nor writing a custom ThreadQueue or Drawing Manager to trace events produces any helpful information.
    Actual results:
    The JProccessBar won't move, and the SwingWorker finishes but the done() method is never run. The PROGRAM is not hung however because if I close the dialog then it will continue.
    Expected results:
    The JProccessBar should always move and the SwingWorker should always run the done() method.
    Additional info:
    java thread dump after freeze, taken with kill -s SIGQUIT <pid>
    2008-06-25 12:25:50
    Full thread dump IcedTea Client VM (1.7.0-b21 mixed mode):
    "DestroyJavaVM" prio=10 tid=0x938afc00 nid=0x1419 waiting on condition
    [0x00000000..0x0018a074]
       java.lang.Thread.State: RUNNABLE
    "AWT-EventQueue-0" prio=10 tid=0x938ae400 nid=0x1429 in Object.wait()
    [0x07f96000..0x07f96f04]
       java.lang.Thread.State: WAITING (on object monitor)
            at java.lang.Object.wait(Native Method)
            - waiting on <0x96748f80> (a java.awt.EventQueue)
            at java.lang.Object.wait(Object.java:503)
            at java.awt.EventQueue.getNextEvent(EventQueue.java:485)
            - locked <0x96748f80> (a java.awt.EventQueue)
            at
    java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java:248)
            at
    java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:201)
            at
    java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:195)
            at java.awt.Dialog$1.run(Dialog.java:1073)
            at java.awt.Dialog$3.run(Dialog.java:1127)
            at java.security.AccessController.doPrivileged(Native Method)
            at java.awt.Dialog.show(Dialog.java:1125)
            at java.awt.Component.show(Component.java:1456)
            at java.awt.Component.setVisible(Component.java:1408)
            at java.awt.Window.setVisible(Window.java:871)
            at java.awt.Dialog.setVisible(Dialog.java:1012)
            at net.xtel.production.WaitDialog.showWaitDialog(WaitDialog.java:72)
            at net.xtel.production.WaitDialog.showWaitDialog(WaitDialog.java:102)
            at TestClass2.showWait(TestClass2.java:79)
            at TestClass2.createAndShowGUI(TestClass2.java:126)
            at TestClass2.access$0(TestClass2.java:114)
            at TestClass2$3.run(TestClass2.java:138)
            at java.awt.event.InvocationEvent.dispatch(InvocationEvent.java:227)
            at java.awt.EventQueue.dispatchEvent(EventQueue.java:603)
            at
    java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java:276)
            at
    java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:201)
            at
    java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:191)
            at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:186)
            at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:178)
            at java.awt.EventDispatchThread.run(EventDispatchThread.java:139)
    "AWT-Shutdown" prio=10 tid=0x938ad000 nid=0x1428 in Object.wait()
    [0x03ea7000..0x03ea7f84]
       java.lang.Thread.State: WAITING (on object monitor)
            at java.lang.Object.wait(Native Method)
            - waiting on <0x96749268> (a java.lang.Object)
            at java.lang.Object.wait(Object.java:503)
            at sun.awt.AWTAutoShutdown.run(AWTAutoShutdown.java:281)
            - locked <0x96749268> (a java.lang.Object)
            at java.lang.Thread.run(Thread.java:675)
    "AWT-XAWT" daemon prio=10 tid=0x938a8400 nid=0x1423 runnable
    [0x02ccc000..0x02ccd104]
       java.lang.Thread.State: RUNNABLE
            at sun.awt.X11.XToolkit.waitForEvents(Native Method)
            at sun.awt.X11.XToolkit.run(XToolkit.java:550)
            at sun.awt.X11.XToolkit.run(XToolkit.java:525)
            at java.lang.Thread.run(Thread.java:675)
    "Java2D Disposer" daemon prio=10 tid=0x93854000 nid=0x1421 in Object.wait()
    [0x07aea000..0x07aead84]
       java.lang.Thread.State: WAITING (on object monitor)
            at java.lang.Object.wait(Native Method)
            - waiting on <0x966e7010> (a java.lang.ref.ReferenceQueue$Lock)
            at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:134)
            - locked <0x966e7010> (a java.lang.ref.ReferenceQueue$Lock)
            at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:150)
            at sun.java2d.Disposer.run(Disposer.java:143)
            at java.lang.Thread.run(Thread.java:675)
    "Low Memory Detector" daemon prio=10 tid=0x93c15000 nid=0x141f runnable
    [0x00000000..0x00000000]
       java.lang.Thread.State: RUNNABLE
    "CompilerThread0" daemon prio=10 tid=0x93c13400 nid=0x141e waiting on condition
    [0x00000000..0x03a8a954]
       java.lang.Thread.State: RUNNABLE
    "Signal Dispatcher" daemon prio=10 tid=0x93c11c00 nid=0x141d waiting on
    condition [0x00000000..0x00000000]
       java.lang.Thread.State: RUNNABLE
    "Finalizer" daemon prio=10 tid=0x095e7000 nid=0x141c in Object.wait()
    [0x005d2000..0x005d3004]
       java.lang.Thread.State: WAITING (on object monitor)
            at java.lang.Object.wait(Native Method)
            - waiting on <0x966e71d8> (a java.lang.ref.ReferenceQueue$Lock)
            at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:134)
            - locked <0x966e71d8> (a java.lang.ref.ReferenceQueue$Lock)
            at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:150)
            at java.lang.ref.Finalizer$FinalizerThread.run(Finalizer.java:177)
    "Reference Handler" daemon prio=10 tid=0x095e2400 nid=0x141b in Object.wait()
    [0x00581000..0x00582084]
       java.lang.Thread.State: WAITING (on object monitor)
            at java.lang.Object.wait(Native Method)
            - waiting on <0x966e7260> (a java.lang.ref.Reference$Lock)
            at java.lang.Object.wait(Object.java:503)
            at java.lang.ref.Reference$ReferenceHandler.run(Reference.java:134)
            - locked <0x966e7260> (a java.lang.ref.Reference$Lock)
    "VM Thread" prio=10 tid=0x095dec00 nid=0x141a runnable
    "VM Periodic Task Thread" prio=10 tid=0x93c17400 nid=0x1420 waiting on condition
    JNI global references: 836
    Heap
    def new generation   total 960K, used 152K [0x93f40000, 0x94040000, 0x966a0000)
      eden space 896K,   9% used [0x93f40000, 0x93f56148, 0x94020000)
      from space 64K, 100% used [0x94020000, 0x94030000, 0x94030000)
      to   space 64K,   0% used [0x94030000, 0x94030000, 0x94040000)
    tenured generation   total 4096K, used 1088K [0x966a0000, 0x96aa0000, 0xb3f40000)
       the space 4096K,  26% used [0x966a0000, 0x967b01b0, 0x967b0200, 0x96aa0000)
    compacting perm gen  total 12288K, used 9169K [0xb3f40000, 0xb4b40000, 0xb7f40000)
       the space 12288K,  74% used [0xb3f40000, 0xb4834740, 0xb4834800, 0xb4b40000)
    No shared spaces configured.CLASS1:
    import java.awt.Dimension;
    import java.awt.Toolkit;
    import java.awt.event.ActionEvent;
    import java.awt.event.ActionListener;
    import java.awt.event.WindowAdapter;
    import java.awt.event.WindowEvent;
    import java.sql.SQLException;
    import java.util.concurrent.ExecutionException;
    import javax.swing.JButton;
    import javax.swing.JFrame;
    import javax.swing.JOptionPane;
    import javax.swing.JPanel;
    import javax.swing.RepaintManager;
    import javax.swing.SwingUtilities;
    import javax.swing.UIManager;
    import javax.swing.UnsupportedLookAndFeelException;
    public class TestClass2 extends JFrame implements ActionListener {
            /** Action Command for <code>searchbtn</code> */
            public static final String SEARCH_BTN_ACTION = "search_btn_action";
             * Constructor.
            public TestClass2() {
                    setSize(650, 350);
                    Dimension screenSize = Toolkit.getDefaultToolkit().getScreenSize();
                    setLocation(screenSize.width / 2 - getSize().width / 2,
                                    screenSize.height / 2 - getSize().height / 2);
                    setDefaultCloseOperation(JFrame.DO_NOTHING_ON_CLOSE);
                    addWindowListener(new WindowAdapter() {
                            @Override
                            public void windowClosing(WindowEvent e) {
                                    exit();
                    JPanel panel = new JPanel();
                    add(panel);
                    setVisible(true);
            @Override
            public void actionPerformed(ActionEvent e) {
                    if (e.getActionCommand().equals(SEARCH_BTN_ACTION)) {
                            JOptionPane.showMessageDialog(this, "Button Pressed");
            public void showWait() {
                    try {
                            WaitDialog.showWaitDialog(this, "Testing...", new SwingWorkerInterface(){
                                    @Override
                                    public Object workToDo() throws Throwable {
                                            Thread.currentThread().sleep(3000);
                                            return null;
                    } catch (InterruptedException e) {
                            // TODO Auto-generated catch block
                            e.printStackTrace();
                    } catch (ExecutionException e) {
                            // TODO Auto-generated catch block
                            e.printStackTrace();
             * Exits the program.
            public void exit(){
                    System.exit(0);
             * Create the GUI and show it. For thread safety, this method should be
             * invoked from the event-dispatching thread.
             * @throws UnsupportedLookAndFeelException
             * @throws IllegalAccessException
             * @throws InstantiationException
             * @throws ClassNotFoundException
             * @throws NullInstanceVariableException
             * @throws SQLException
            private static void createAndShowGUI() {
                    // set look and feel
                    try{
                            UIManager.setLookAndFeel(UIManager.getSystemLookAndFeelClassName());
                            // Create instance of the ProductCatalog
                            TestClass2 root = new TestClass2();
                            for(int i = 0; i < 10; i++){
                                    root.showWait();
                    }catch(Exception e){
                            e.printStackTrace();
             * @param args
             *            this program does not use arguments
            public static void main(String[] args) {
                    SwingUtilities.invokeLater(new Runnable() {
                            public void run() {
                                    createAndShowGUI();
    }CLASS 2:
    import java.awt.Component;
    import java.awt.Frame;
    import java.awt.event.WindowAdapter;
    import java.awt.event.WindowEvent;
    import java.util.concurrent.ExecutionException;
    import javax.swing.JDialog;
    import javax.swing.JFrame;
    import javax.swing.JLabel;
    import javax.swing.JOptionPane;
    import javax.swing.JPanel;
    import javax.swing.JProgressBar;
    import javax.swing.SwingWorker;
    public class WaitDialog extends JDialog {
            private boolean disposed = false;
            private boolean displayed = false;
            private WorkerThread worker = null;
            WaitDialog(Frame parent, String text, SwingWorkerInterface in){
                    super(parent, true);
                    worker = new WorkerThread(in);
                    setDefaultCloseOperation(JFrame.DO_NOTHING_ON_CLOSE);
                    addWindowListener(new WindowAdapter() {
                            @Override
                            public void windowOpened(WindowEvent e) {
                                    worker.execute();
                            @Override
                            public void windowClosing(WindowEvent e) {
                                    disposeWaitDialog();
                    this.setResizable(false);
                    JLabel message = new JLabel();
                    message.setText(text);
                    JProgressBar pb = new JProgressBar();
                    pb.setIndeterminate(true);
                    // set size and location
                    setSize(200, 100);
                    setLocationRelativeTo(parent);
                    JPanel panel = new JPanel();
                    panel.add(message);
                    panel.add(pb);
                    add(panel);
            public void showWaitDialog(){
                    if(displayed == true){
                            return;
                    if(disposed == true){
                            disposed = false;
                            return;
                    disposed = false;
                    displayed = true;
                    setVisible(true);
            public void disposeWaitDialog(){
                    if(disposed == true){
                            return;
                    if(displayed == true){
                            displayed = false;
                            setVisible(false);
                            return;
                    disposed = true;
                    displayed = false;
            public static Object showWaitDialog(Component parent, String text, SwingWorkerInterface in) throws InterruptedException, ExecutionException {
                    WaitDialog waitDialog = null;
                    if (parent == null) {
                            waitDialog = new WaitDialog(JOptionPane.getRootFrame(), text, in);
                    } else {
                            waitDialog = new WaitDialog(JOptionPane.getFrameForComponent(parent), text, in);
                    while(!waitDialog.worker.isDone()){
                            System.out.println("about to show");
                            waitDialog.showWaitDialog();
                            System.out.println("done showing");
                    waitDialog.dispose();
                    return waitDialog.worker.get();
            class WorkerThread extends SwingWorker<Throwable, Void> {
                    private SwingWorkerInterface in = null;
                    WorkerThread(SwingWorkerInterface in){
                            this.in = in;
                    public Throwable doInBackground(){
                                    try {
                                            System.out.println("about to do work");
                                            in.workToDo();
                                            System.out.println("done work no exception");
                                    } catch (Throwable e) {
                                            System.out.println("done work with exception");
                                            return e;
                                    return null;
                    public void done(){
                                    System.out.println("about to dispose");
                                    disposeWaitDialog();
                                    System.out.println("disposed");
    }CLASS 3:
    public interface SwingWorkerInterface {
            public Object workToDo() throws Throwable;
    }

    There's nothing directly wrong with it, but it will
    prevent other threads acquiring the class lock - but
    that may be what you want.True. Although the typical case for code that looks like this would be to use wait--usually the various threads in question require the same lock, so you have to use wait in order for the waiting thread to give it up and allow the other thread to do its work. Hard to say for sure though what he's doing.
    Also, if loading is all that the other thread does, and you're waiting for that thread to die, use join. But then, if that's the case, and you're only waiting for a single other thread, then you might as well just put it all in one thread, as already indicated.

  • An event in one of my libraries no longer has the event icon next to it's name just the name only. I can't view the clips in the event or import new clips. I've tried deleting the event and nothing.

    an event in one of my libraries no longer has the event icon next to it's name in the browser just the name only. I can't view the clips in the event or import new clips. I've tried deleting the event and nothing. After control clicking the event it shows all the media that has been previously imported. But it does not allow anything to be done to the event including deleting. This showed up at the beginning of a normal import session. This is fortunately the back-up evant.

    Did you perhaps mess with the contents of the library in the Finder?
    You may try the solution suggested in this thread:
    https://discussions.apple.com/message/24915790#24915790

  • RE: Re[2]: Service Object events and LockMgr

    I think there are a lot to implement a lock manager. If several objects
    should be updated in one transaction, the lock manager should be able to
    handle rollbacks. Other things like release lock when exception happens,
    avoiding dead locks, etc. Most of the features are provided by DBMS, so
    I think using a option 2 would be a better solution.
    -----Original Message-----
    From: Dimitar Gospodinov [mailto:[email protected]]
    Sent: Wednesday, July 28, 1999 2:44 PM
    To: Peter Sham
    Cc: Duncan Kinnear; [email protected]
    Subject: Re[2]: Service Object events and LockMgr
    Hello Peter,
    Wednesday, July 28, 1999, 9:19:10 PM, you wrote:
    PS> Hi,
    PS> Just wonder exactly how this Lock Manager can be
    implemented. Do you mean that you are
    PS> going to cache every object that is instantiated from the
    database? Or you just cache
    PS> the object id, primary key, etc?
    PS> Frankly speaking, I won't attempt to due with this kind
    of currency coding myself as
    PS> the database vendor has spent years in coding just to do this.
    PS> Regards.
    The second one - you just need some unique value that will identify
    the object being locked. You should register with the Lock
    Manager only
    the objects that you want to lock.
    For me, one of the goal of such pattern is to give you some freedom
    from the specifics of the database lock mechanism.
    Another benefit that I can see is that using such approach you can
    always answer to the question: "Can I modify/delete this object?".
    Best regards,
    Dimitar mailto:[email protected]
    To unsubscribe, email '[email protected]' with
    'unsubscribe forte-users' as the body of the message.
    Searchable thread archive
    <URL:http://pinehurst.sageit.com/listarchive/forte>
    To unsubscribe, email '[email protected]' with
    'unsubscribe forte-users' as the body of the message.
    Searchable thread archive <URL:http://pinehurst.sageit.com/listarchive/forte>

    I think there are a lot to implement a lock manager. If several objects
    should be updated in one transaction, the lock manager should be able to
    handle rollbacks. Other things like release lock when exception happens,
    avoiding dead locks, etc. Most of the features are provided by DBMS, so
    I think using a option 2 would be a better solution.
    -----Original Message-----
    From: Dimitar Gospodinov [mailto:[email protected]]
    Sent: Wednesday, July 28, 1999 2:44 PM
    To: Peter Sham
    Cc: Duncan Kinnear; [email protected]
    Subject: Re[2]: Service Object events and LockMgr
    Hello Peter,
    Wednesday, July 28, 1999, 9:19:10 PM, you wrote:
    PS> Hi,
    PS> Just wonder exactly how this Lock Manager can be
    implemented. Do you mean that you are
    PS> going to cache every object that is instantiated from the
    database? Or you just cache
    PS> the object id, primary key, etc?
    PS> Frankly speaking, I won't attempt to due with this kind
    of currency coding myself as
    PS> the database vendor has spent years in coding just to do this.
    PS> Regards.
    The second one - you just need some unique value that will identify
    the object being locked. You should register with the Lock
    Manager only
    the objects that you want to lock.
    For me, one of the goal of such pattern is to give you some freedom
    from the specifics of the database lock mechanism.
    Another benefit that I can see is that using such approach you can
    always answer to the question: "Can I modify/delete this object?".
    Best regards,
    Dimitar mailto:[email protected]
    To unsubscribe, email '[email protected]' with
    'unsubscribe forte-users' as the body of the message.
    Searchable thread archive
    <URL:http://pinehurst.sageit.com/listarchive/forte>
    To unsubscribe, email '[email protected]' with
    'unsubscribe forte-users' as the body of the message.
    Searchable thread archive <URL:http://pinehurst.sageit.com/listarchive/forte>

  • Re: Service Object events and LockMgr

    On the option that you have considered, I have implemented the same model
    in my previous project (using Java/RMI), but I felt that it is more than
    what is normally needed for concurrency protection.
    I can suggest another option that is worth considering which is in place in
    our app for concurrency.
    Almost every table in our db has created By, created On, modifed By,
    modified On columns. The parent class of all business objects has
    attributes that correspond to these four columns. In addition to these
    four, there is a fifth attribute (introduced when concurrency was built)
    called originalModifiedOn. Upon retrieval from the db, it is set to
    modifiedOn value (from the db), during UPDATE, the value in this column is
    added part of the WHERE clause. So when the second user tried to do save
    the same object, the underlying db update will get a 'zero rows updated'
    which is translated into an application error 'possible concurrency
    error'. The user re-retreives the now 'stale' object before applying their
    edits.
    A lot of these things are and can be built into the framework imposing very
    little work that each Object needs to do to have concurrency protection.
    I am not sure if there is a mention in the Patterns paper of this model,
    but it is very easy to implement and supports what is needed.
    Kishore Puvvada's Mail
    [email protected] on 07/28/99 01:47:00 AM
    To: [email protected]@INTERNET
    cc: (bcc: Kishore Puvvada/HQ-IS/TAL)
    Subject: Service Object events and LockMgr
    Hi folks,
    We're currently looking at strategies for dealing with the simultaneous
    updates to the database from multiple clients (concurrency
    management). That is when two (or more) clients load the same object to
    edit it, then make different changes and save them to the database.
    We have a copy of a Fort&eacute; document (from the "Patterns" course, I
    think) which describes three methods of dealing with this:
    1) Lock the database table row as soon as a client select it for editing
    and hold the lock until it is saved.
    2) Immediately before 'saving' check that the database hasn't changed
    (either by reading what's there before updating, or by using a huge
    'where' clause that contains all unchanged fields)
    3) The Fort&eacute; "LockMgr" pattern, which uses a service object with notifier
    proxies to allow locking and updating notification between the clients.
    Option 3 is obviously the most robust method, but it requires a fair
    amount of coding and could also be a bottleneck for database reads and
    writes.
    But I have another option for which I was looking for opinions. What if
    we had a "Change Event manager" which broadcast an event every time
    a change is made to the database. Each business class would have its
    own event. If the event had the object's primary key as a parameter, then
    clients editing that particular object type could check to see if the object
    currently on screen is the one that changed. That way you could disable
    the 'save' until they had refreshed their on-screen data.
    It's not particularily elegant, but it's reasonably simple to implement. It
    also deals with changes sent across our WAN from other database
    servers.
    But this option is only worthwhile if you can replicate the "Change Event
    manager" SO and still register for an event on the client. Can clients
    register for SO events and receive an event generated by any of the SO's
    replicates? Or when you register for an SO's event do you register for
    only one instance of the SO?
    Thanks in advance for any answers.
    Cheers,
    Duncan Kinnear,
    McCarthy and Associates, Email:
    [email protected]
    PO Box 764, McLean Towers, Phone: +64 6 834 3360
    Shakespeare Road, Napier, New Zealand. Fax: +64 6 834 3369
    Providing Integrated Software to the Meat Processing Industry for over 10
    years
    To unsubscribe, email '[email protected]' with
    'unsubscribe forte-users' as the body of the message.
    Searchable thread archive <URL:
    http://pinehurst.sageit.com/listarchive/forte>
    To unsubscribe, email '[email protected]' with
    'unsubscribe forte-users' as the body of the message.
    Searchable thread archive <URL:http://pinehurst.sageit.com/listarchive/forte>

    On the option that you have considered, I have implemented the same model
    in my previous project (using Java/RMI), but I felt that it is more than
    what is normally needed for concurrency protection.
    I can suggest another option that is worth considering which is in place in
    our app for concurrency.
    Almost every table in our db has created By, created On, modifed By,
    modified On columns. The parent class of all business objects has
    attributes that correspond to these four columns. In addition to these
    four, there is a fifth attribute (introduced when concurrency was built)
    called originalModifiedOn. Upon retrieval from the db, it is set to
    modifiedOn value (from the db), during UPDATE, the value in this column is
    added part of the WHERE clause. So when the second user tried to do save
    the same object, the underlying db update will get a 'zero rows updated'
    which is translated into an application error 'possible concurrency
    error'. The user re-retreives the now 'stale' object before applying their
    edits.
    A lot of these things are and can be built into the framework imposing very
    little work that each Object needs to do to have concurrency protection.
    I am not sure if there is a mention in the Patterns paper of this model,
    but it is very easy to implement and supports what is needed.
    Kishore Puvvada's Mail
    [email protected] on 07/28/99 01:47:00 AM
    To: [email protected]@INTERNET
    cc: (bcc: Kishore Puvvada/HQ-IS/TAL)
    Subject: Service Object events and LockMgr
    Hi folks,
    We're currently looking at strategies for dealing with the simultaneous
    updates to the database from multiple clients (concurrency
    management). That is when two (or more) clients load the same object to
    edit it, then make different changes and save them to the database.
    We have a copy of a Fort&eacute; document (from the "Patterns" course, I
    think) which describes three methods of dealing with this:
    1) Lock the database table row as soon as a client select it for editing
    and hold the lock until it is saved.
    2) Immediately before 'saving' check that the database hasn't changed
    (either by reading what's there before updating, or by using a huge
    'where' clause that contains all unchanged fields)
    3) The Fort&eacute; "LockMgr" pattern, which uses a service object with notifier
    proxies to allow locking and updating notification between the clients.
    Option 3 is obviously the most robust method, but it requires a fair
    amount of coding and could also be a bottleneck for database reads and
    writes.
    But I have another option for which I was looking for opinions. What if
    we had a "Change Event manager" which broadcast an event every time
    a change is made to the database. Each business class would have its
    own event. If the event had the object's primary key as a parameter, then
    clients editing that particular object type could check to see if the object
    currently on screen is the one that changed. That way you could disable
    the 'save' until they had refreshed their on-screen data.
    It's not particularily elegant, but it's reasonably simple to implement. It
    also deals with changes sent across our WAN from other database
    servers.
    But this option is only worthwhile if you can replicate the "Change Event
    manager" SO and still register for an event on the client. Can clients
    register for SO events and receive an event generated by any of the SO's
    replicates? Or when you register for an SO's event do you register for
    only one instance of the SO?
    Thanks in advance for any answers.
    Cheers,
    Duncan Kinnear,
    McCarthy and Associates, Email:
    [email protected]
    PO Box 764, McLean Towers, Phone: +64 6 834 3360
    Shakespeare Road, Napier, New Zealand. Fax: +64 6 834 3369
    Providing Integrated Software to the Meat Processing Industry for over 10
    years
    To unsubscribe, email '[email protected]' with
    'unsubscribe forte-users' as the body of the message.
    Searchable thread archive <URL:
    http://pinehurst.sageit.com/listarchive/forte>
    To unsubscribe, email '[email protected]' with
    'unsubscribe forte-users' as the body of the message.
    Searchable thread archive <URL:http://pinehurst.sageit.com/listarchive/forte>

  • Service Object events and LockMgr

    Hi folks,
    We're currently looking at strategies for dealing with the simultaneous
    updates to the database from multiple clients (concurrency
    management). That is when two (or more) clients load the same object to
    edit it, then make different changes and save them to the database.
    We have a copy of a Fort&eacute; document (from the "Patterns" course, I
    think) which describes three methods of dealing with this:
    1) Lock the database table row as soon as a client select it for editing
    and hold the lock until it is saved.
    2) Immediately before 'saving' check that the database hasn't changed
    (either by reading what's there before updating, or by using a huge
    'where' clause that contains all unchanged fields)
    3) The Fort&eacute; "LockMgr" pattern, which uses a service object with notifier
    proxies to allow locking and updating notification between the clients.
    Option 3 is obviously the most robust method, but it requires a fair
    amount of coding and could also be a bottleneck for database reads and
    writes.
    But I have another option for which I was looking for opinions. What if
    we had a "Change Event manager" which broadcast an event every time
    a change is made to the database. Each business class would have its
    own event. If the event had the object's primary key as a parameter, then
    clients editing that particular object type could check to see if the object
    currently on screen is the one that changed. That way you could disable
    the 'save' until they had refreshed their on-screen data.
    It's not particularily elegant, but it's reasonably simple to implement. It
    also deals with changes sent across our WAN from other database
    servers.
    But this option is only worthwhile if you can replicate the "Change Event
    manager" SO and still register for an event on the client. Can clients
    register for SO events and receive an event generated by any of the SO's
    replicates? Or when you register for an SO's event do you register for
    only one instance of the SO?
    Thanks in advance for any answers.
    Cheers,
    Duncan Kinnear,
    McCarthy and Associates, Email: [email protected]
    PO Box 764, McLean Towers, Phone: +64 6 834 3360
    Shakespeare Road, Napier, New Zealand. Fax: +64 6 834 3369
    Providing Integrated Software to the Meat Processing Industry for over 10 years
    To unsubscribe, email '[email protected]' with
    'unsubscribe forte-users' as the body of the message.
    Searchable thread archive <URL:http://pinehurst.sageit.com/listarchive/forte>

    Hi,
    Just wonder exactly how this Lock Manager can be implemented. Do you mean that you are
    going to cache every object that is instantiated from the database? Or you just cache
    the object id, primary key, etc?
    Frankly speaking, I won't attempt to due with this kind of currency coding myself as
    the database vendor has spent years in coding just to do this.
    Regards.
    Dimitar Gospodinov wrote:
    Hello Duncan,
    Wednesday, July 28, 1999, 10:31:46 AM, you wrote:
    DK> Hi folks,
    DK> We're currently looking at strategies for dealing with the simultaneous
    DK> updates to the database from multiple clients (concurrency
    DK> management). That is when two (or more) clients load the same object to
    DK> edit it, then make different changes and save them to the database.
    DK> We have a copy of a Fort&eacute; document (from the "Patterns" course, I
    DK> think) which describes three methods of dealing with this:
    DK> 1) Lock the database table row as soon as a client select it for editing
    DK> and hold the lock until it is saved.
    DK> 2) Immediately before 'saving' check that the database hasn't changed
    DK> (either by reading what's there before updating, or by using a huge
    DK> 'where' clause that contains all unchanged fields)
    DK> 3) The Fort&eacute; "LockMgr" pattern, which uses a service object with notifier
    DK> proxies to allow locking and updating notification between the clients.
    DK> Option 3 is obviously the most robust method, but it requires a fair
    DK> amount of coding and could also be a bottleneck for database reads and
    DK> writes.
    DK> But I have another option for which I was looking for opinions. What if
    DK> we had a "Change Event manager" which broadcast an event every time
    DK> a change is made to the database. Each business class would have its
    DK> own event. If the event had the object's primary key as a parameter, then
    DK> clients editing that particular object type could check to see if the object
    DK> currently on screen is the one that changed. That way you could disable
    DK> the 'save' until they had refreshed their on-screen data.
    DK> It's not particularily elegant, but it's reasonably simple to implement. It
    DK> also deals with changes sent across our WAN from other database
    DK> servers.
    DK> But this option is only worthwhile if you can replicate the "Change Event
    DK> manager" SO and still register for an event on the client. Can clients
    DK> register for SO events and receive an event generated by any of the SO's
    DK> replicates? Or when you register for an SO's event do you register for
    DK> only one instance of the SO?
    DK> Thanks in advance for any answers.
    DK> Cheers,
    DK> Duncan Kinnear,
    DK> McCarthy and Associates, Email: [email protected]
    DK> PO Box 764, McLean Towers, Phone: +64 6 834 3360
    DK> Shakespeare Road, Napier, New Zealand. Fax: +64 6 834 3369
    DK> -------------------------------------------------------------------------------
    DK> Providing Integrated Software to the Meat Processing Industry for over 10 years
    DK> -
    DK> To unsubscribe, email '[email protected]' with
    DK> 'unsubscribe forte-users' as the body of the message.
    DK> Searchable thread archive <URL:http://pinehurst.sageit.com/listarchive/forte>
    I would recommend you to use the following approach (of course if you
    do not have some special requirements :) ):
    1. You should have a LockManager that will synchronize all clients in
    their attempt to modify/delete objects in your application.
    2. Each client, when attempts to modify/delete some object, it must
    LOCK it using the services provided with the LockManager.
    3. The requested operation can be performed only after successful
    locking.
    4. If a lock can not be obtained (for example if the object is already
    locked by some other client) then the operation is aborted.
    The details of this pattern depends on your needs. :)
    Hope this helps.
    Best regards,
    Dimitar mailto:[email protected]
    To unsubscribe, email '[email protected]' with
    'unsubscribe forte-users' as the body of the message.
    Searchable thread archive <URL:http://pinehurst.sageit.com/listarchive/forte>-
    To unsubscribe, email '[email protected]' with
    'unsubscribe forte-users' as the body of the message.
    Searchable thread archive <URL:http://pinehurst.sageit.com/listarchive/forte>

  • Windows 7 Ultimate 64 bit: Events and Errors

    Clicking on “Event Log Online Help” (every event in “Event Viewer”) results in:
    Page:
    http://www.microsoft.com/technet/support/ee/SearchResults.aspx?Type=1&Fallback=1&Source=Application%20Hang&ID=1002&Product=Windows%20Operating%20System&Version=6.1.7600.16385&Language=6153
     “Events and Errors Message Center”:
    “Results for: Microsoft Product: Windows Operating System; Version: 6.1.7600.16385; Event ID: X; Event Source: Y”
    “No results were found for your query. Please see Search Help for suggestions.”
    Fulco

    Hi,
    By default, Event Log Online Help redirects to
    Events and Errors Message Center. It seems that the path of
    MicrosoftRedirectionURL is incorrect. Please look into the following registry and modify  the URL path:
    1)   
    Click Start and type:
    regedit in the Search box.
    2)   
    Open Registry Editor and find the entry:
    HKLM\Software\Microsoft\Windows NT\CurrentVersion\EventViewer
    3)   
    Double click the
    MicrosoftRedirectionURL and change the path using:
    http://go.microsoft.com/fwlink/events.asp
    The above link navigates to
    Events and Errors Message Center. If the issue persists,  you can use the following URL instead:
    http://www.microsoft.com/technet/support/ee/ee_basic.aspx
    Now you should open Event Log Online Help correctly.  
    Best Regards
    Dale
    Please remember to click “Mark as Answer” on the post that helps you, and to click “Unmark as Answer” if a marked post does not actually answer your question. This can be beneficial to other community members reading the thread. ”

  • How to use the eventing and databag with a WAS 6.20 ?

    How to use the eventing and databag with a WAS 6.20 ?
    Is what there is a good guide for these services?
    Thank's

    In the raise event you can pass the value
    like below.
    <SCRIPT>
    function raiseEvt(value1){
    if(window.document.domain == window.location.hostname){
    if ( document.domain.indexOf(".") > 0 ) document.domain = document.domain.substr(document.domain.indexOf(".")+1);
       EPCMPROXY.raiseEvent( "urn:com.sap:BWEvents","BWiViewevent", value1, null );
      // alert('tree domain'+document.domain);
    </SCRIPT>
    and in the
    subscribe event you can get the values like below.
    <script language="javascript">
    if(window.document.domain == window.location.hostname){
    document.domain = document.domain.substring(document.domain.indexOf('.')+1);
        EPCMPROXY.subscribeEvent("urn:com.sap:BWEvents","BWiViewevent", window, "myreceiveEvent");
    function myreceiveEvent( eventObj ) {
          document.forms[0].gp_hidden.value = eventObj.dataObject;
    </script>
    Also look at the following link for a complete documentation.
    https://www.sdn.sap.com/irj/servlet/prt/portal/prtroot/com.sap.km.cm.docs/documents/a1-8-4/Enterprise%20Portal%20Client.pdf
    Regards
    Raja

  • Weblogic Enterprise 5.1 and threads

    I know when building servers based on WLE 4.2 in was a big no-no to link in threading libraries like pthread and thread. Is this still the case in Weblogic Enterprise 5.1?

    According to the product information, WLE 5.1 does not support Oracle 8.1.6, it
    only goes up to
    Oracle 8.1.5. But in general, I thought that with oracle there are 2 sets of
    libraries, one for threads and
    one for non-threaded support. You need to use the correct one, in the case of
    WLE, that would be the
    non-threaded one.
    MAS
    Paul Power wrote:
    Thanks Mary,
    Do you know of any customers who have managed to work
    with Oracle 8.1.6 without linking with the thread libraries ?
    cheers,
    P.
    Mary Ann Slavin wrote in message <[email protected]>...
    WLE 5.1 C++ is not a threaded product. Compiling WLE 5.1 C++ with thread
    libraries is not supported and will give unpredictable results for allprograms.
    This should not be done.
    Paul Power wrote:
    Hi Mary,
    Is it a dictate from BEA that you "can't" link with thread libraries ?
    We are using WLE 5.0.1 ( and some 5.1) with Oracle 8.1.6 on
    Solaris and found that we had to link using -lthread in order to use
    Oracle (not the case in 8.1.5)
    We don't actually attempt to try any threading in our apps and
    have not had any problems yet but if it's the case that there
    are known problems using threads we'd love to hear about
    them :-)
    As an aside, is Oracle 8.1.6 cleared for use by WLE ?
    P.
    Mary Ann Slavin wrote in message <[email protected]>...
    No matter how WLE 5.1 C++ is used, it cannot be compiled with threadedlibraries, so that restriction remains.
    A WLE C++ server can act as a client and call a WLE Java Server. Doingthis does not require the WLE C++ server to be compiled with threaded
    libraries.
    Wendell MacKenzie wrote:
    Does this also mean if CORBA C++ servers want to invoke threaded
    JavaServers
    the same DEFECT will be prevent this from being accomplished?
    Mary Ann Slavin wrote:
    WLE 5.1 does not have threads in the C++ clients or servers. Java
    threads are naturally occuring in the language, however, there are WLE
    restrictions on what can be done in the
    Java threads. These are documented.
    jd wrote:
    I know when building servers based on WLE 4.2 in was a big no-no
    to
    link in threading libraries like pthread and thread. Is this still thecase
    in Weblogic Enterprise 5.1?
    >

Maybe you are looking for