> -----Original Message----- > From: Dain Sundstrom [mailto:[EMAIL PROTECTED] > Sent: Friday, December 08, 2006 1:12 PM > To: open-jpa-dev@incubator.apache.org > Subject: Re: Flush all caches? > > On Dec 8, 2006, at 11:29 AM, Abe White wrote: > > >> Other than the cost of not having a cache (which is what I want), > >> it is expensive to be creating a new EntityManager for each > >> transaction? > > > > No. > > In general, is it a good strategy to use a new EntityManager > for each > transaction?
There's certainly nothing wrong with that approach. However, the situation is not as simple as it seems. When used in a JTA environment, by default an EntityManager will use a transactional persistence context. This means that each transaction essentially automatically gets a new EntityManager under the covers, and each operation that happens outside a transaction happens in its own under-the-covers-EntityManager as well. So, if you're in a JTA environment and haven't configured yourself to use extended persistence contexts, then there's really no difference between getting a new EM or reusing the existing one. Think of a transactional-PC JTA EntityManager as a proxy, rather than a real EM. > I think it is great for testing, but I am concerned about having to > write code two different ways, one for single node deployment and > another way for a clustered deployment. It's worth noting that there are two different caches in play in OpenJPA -- the EM-level cache (which is coincident with the persistence context terminology in the spec, and I like to think of as a "working set" instead of a "cache"), and the EMF-level cache. Modulo not having a way to clear all EMF-level caches in a cluster, there should be no difference between clustered behavior and non-clustered behavior in your code. In any event, I kinda feel like there's a bit of a disconnect between my assumptions and yours; lemme know if you've got the same feeling. -Patrick _______________________________________________________________________ Notice: This email message, together with any attachments, may contain information of BEA Systems, Inc., its subsidiaries and affiliated entities, that may be confidential, proprietary, copyrighted and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it.