The other thing to consider is the liveness of the application.

If you have tied up your thread talking to the server via the EntityManager, nothing will happen until the operation completes. So having multiple EntityManagers might be useful to preserve liveness.

Craig

On Jan 29, 2008, at 11:39 AM, Patrick Linskey wrote:

If you want to allow multiple concurrent transactions, you'll need to
have multiple EntityManagers. For example, if you want a given network
operation to happen in a separate transaction while other
transactional work is happening, you'll need a separate EM for that
network operation. You can probably avoid this complexity if you defer
all the database work until the end of the network operation, but the
right answer will really depend on what you want your business process
to look like.

If you end up with multiple EMs, you can register a
TransactionListener to notify the main GUI EM when a different EM
modifies data.

-Patrick

On Jan 29, 2008 9:39 AM, ktj <[EMAIL PROTECTED]> wrote:

Regarding the relationship of the EntityManager to a Transaction: since there is a one-to-one EntityManager-to-Transaction relationship, and we will only have one EntityManager, it seems that, for us, transactions will be similar
to flush?

Assuming we have two Entities, a and b,

// modify A outside 'transaction'
a.setFoo...

EntityTransaction t = em.getTransaction();
t.begin();
// modify B inside transaction
b.setBar...
t.commit(); // commits changes to a and b
-or-
t.rollback(); // rolls back changes to a and b


Is this correct?

If this is correct, why does 'flush' need a transaction?
(EntityManager.flush throws TransactionRequiredException otherwise)



--
View this message in context: 
http://www.nabble.com/Extended-Persistence-Context-in-multi-threaded-app-tp15160167p15164994.html

Sent from the OpenJPA Users mailing list archive at Nabble.com.





--
Patrick Linskey
202 669 5907

Craig Russell
Architect, Sun Java Enterprise System http://java.sun.com/products/jdo
408 276-5638 mailto:[EMAIL PROTECTED]
P.S. A good JDO? O, Gasp!

Attachment: smime.p7s
Description: S/MIME cryptographic signature

Reply via email to