On Dec 11, 2006, at 2:09 AM, Patrick Linskey wrote:
>> -----Original Message-----
>> From: Dain Sundstrom [mailto:dain@iq80.com]
>> 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
|