Mailing-List: contact open-jpa-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: open-jpa-dev@incubator.apache.org
Received-SPF: pass (herse.apache.org: domain of plinskey@bea.com designates
 66.248.192.22 as permitted sender)
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: Flush all caches?
Date: Mon, 11 Dec 2006 02:09:49 -0800
Message-ID: <7D856CDFE035FF45A0420ACBD71BDD6302A2E051@repbex02.amer.bea.com>
In-Reply-To: <2E174C81-6D16-457E-854A-E1EA500CA984@iq80.com>
Thread-Topic: Flush all caches?
Thread-Index: AccbDaRLvTDAPMANTxCk+CzlsYcY+AByNygw
From: "Patrick Linskey" <plinskey@bea.com>
To: <open-jpa-dev@incubator.apache.org>

> -----Original Message-----
> From: Dain Sundstrom [mailto:dain@iq80.com]=20
> Sent: Friday, December 08, 2006 1:12 PM
> To: open-jpa-dev@incubator.apache.org
> Subject: Re: Flush all caches?
>=20
> On Dec 8, 2006, at 11:29 AM, Abe White wrote:
>=20
> >> Other than the cost of not having a cache (which is what I want),=20=
=20
> >> it is expensive to be creating a new EntityManager for each=20=20
> >> transaction?
> >
> > No.
>=20
> In general, is it a good strategy to use a new EntityManager=20
> for each=20=20
> transaction?

There's certainly nothing wrong with that approach.=20

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=20=20
> write code two different ways, one for single node deployment and=20=20
> 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.=20

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.