openjpa-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dain Sundstrom <d...@iq80.com>
Subject Re: Flush all caches?
Date Mon, 11 Dec 2006 17:58:04 GMT
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

Mime
View raw message