On Dec 11, 2006, at 2:09 AM, Patrick Linskey wrote:
-----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.
Interesting. Is this something the Jee server manages for you or is
this something inherently in OpenJPA? The reason I ask is because
I'm not using server managed entity managers. Instead, I am
constructing them directly using a PersistenceUnitInfo.
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.
Cool. That is exactly what I expected under the covers, but I didn't
know which objects was managing which cache or how to clear them.
With this explanation, I think I will be much better equipped to
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.
Not sure, but let me fill you in on what I'm doing.
To start with, I'm trying to write a few small example test cases for
simple beans, one-to-one, one-to-many and many-to-many. I've run
into enough set backs while coding my real stuff that I want simple
standalone tests to verify that OpenJPA is working and my code is
wrong, which has always been the case so far :) One common problem
I have run into is that my beans get cached in the EMF and my tests
pass even though the database is not being updated, so I have tests
that muck with the database directly to assure that OpenJPA is
grabbing the real data. This is why I keep asking about caches and
clustering (since my JDBC code looks like a clustered server to
OpenJPA).
I'm really working on a replacement for the OpenEJB Castor CMP
container that uses OpenJPA instead. I'm just hacking in the CMRs
right now, hence all the relationship questions. I hope to have the
basics done in a few days.
-dain
