openjpa-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Patrick Linskey" <>
Subject RE: Flush all caches?
Date Mon, 11 Dec 2006 22:41:18 GMT
> > 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.

Interesting indeed. It's behavior that can be implemented just by an
appserver, but Kodo also has properties to handle the work internally.
You might be triggering that behavior by using a PUInfo to initialize;
how are you doing that exactly? The spec defines that the way to get
"application-managed" EMs is via a call to
Persistence.createEntityManager(). "Container-managed" EMs come from
PersistenceProvider.createContainerEntityManager() (or something like
that). I'm not sure where OpenJPA's persistence context defaults get
applied in which way.

This gets configured via the openjpa.AutoDetach property.

> > 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).

It's really surprising that the cache would get updated but the database
would not. The cache should not be populated until after the SQL
statements are issued. Are you seeing things in the database that do not
correspond with what you see in the SQL logs?

> 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.

Ah. That probably explains it. JPA is designed kinda to assume that you
manage both sides of relationships in your own domain code, since it can
get tricky to do the right thing with raw exposed lists etc. OpenJPA
does have some inverse management capabilities that go a certain extent
towards the same behavior as CMR in EJB2. Check out the docs on the
openjpa.InverseManager property.

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.

View raw message