On Dec 11, 2006, at 2:41 PM, Patrick Linskey wrote:

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?

Easy. Create an implementation of PUInfo, create one, populate it, and pass it to OpenJPA.

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

App managed em suck because you can't use JTA transactions. Also I'm targeting an app managed environment, but I don't want to run in it with small tests.

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?

In every case so far, it was because I didn't have my mappings correct or I missed one, so OpenJPA just treats it as a transient field.

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.

That's what I'm coding.. the update both sides stuff

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.

Sweet! I'll look for that. It may not work since I need to wrap and unwrap ejb proxies.

-dain

Reply via email to