> calling some setters on it in the Event Dispatch Thread. That is not the "correct" programming model. EDT - a singular thread - pumps events for the visual widgets and any non-visual operation on EDT has the potential of slowing or blocking the GUI. That is the central idea behind Swing Worker or SwingUtilities.invokeLater() etc. to keep EDT free at all times to do its own task -- which is to dispatch events to Swing widgets.
Thus a "proper" Swing based application that access/modify data is essentially a client-server model though operating on the same process space -- where any "data-oriented" operation is a call to the "server" and executed on some non-EDT thread while any operation that updates the Swing widgets is executed on EDT. SwingWorker makes that pattern easily accessible to the developers. So in this context, any JPA interaction is "server" operation -- and the common pattern for that is query-detach-modify (remotely)-merge cycle. Deviation from this pattern has its own peril. Now whether the "JPA server" is single-threaded or multi-threaded, whether it uses a single EntityManager or many EntityManagers, whether a single EntityManager is accessed by multiple threads or each thread gets its own EntityManager -- those are questions best answered by the given application semantics. But these are orthogonal considerations from the client's threading model. OpenBooks, for example, uses a single-session-per-thread model for all its JPA operation while the Swing client uses SwingWorker's pattern to enforce a clean separation between GUI and non-GUI tasks in separate threads. ----- Pinaki -- View this message in context: http://openjpa.208410.n2.nabble.com/Calling-a-getter-of-an-entity-will-access-the-broker-tp5325919p5342319.html Sent from the OpenJPA Users mailing list archive at Nabble.com.
