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