I used the term "client-server" model as a programming model abstraction that, in this case, is used to decouple the threading model of the "client" i.e. the Swing widgets and the "server" i.e. the operations that use JPA. They operate in the same process but still can use a decoupled threading model. SwingWorker, as I understand, is designed to facilitate such a programming/threading model especially for Swing-based application. That is why SwingWorker provides two separate methods namely: doInBackground() and done() to ensure that "server" operations are executed in separate thread than the GUI update. Your example does neither show where worker's execute() or get() method is called nor how its done() is processed. So I can not definitely comment about its efficacy. The code snippet however does not address the critical issue of *which* entity manager is being used in doInBackground() method or how is that obtained -- the decisions that are critical in getting things right. At the cost of repeating myself, a reasonably non-trivial complete sample is made available via OpenBooks to demonstrate the usage as we deem fit for a single process Swing application to work with JPA without sacrificing the responsiveness of GUI. In that example you can see examples of how SwingWorker is used for operations that block the GUI (where the result of the operation is essential to proceed further in GUI interaction) versus those operations that can occur truly in "background".
----- Pinaki -- View this message in context: http://openjpa.208410.n2.nabble.com/Calling-a-getter-of-an-entity-will-access-the-broker-tp5325919p5342683.html Sent from the OpenJPA Users mailing list archive at Nabble.com.
