> This means that we use the UpdateManager to filter the set of JPA objects and to pass forward only those JPA entities that we want be explicitly insert or update in the database.
I don't think that your approach is going to work. If you look at the UpdateManager interface, you'll see that the contract states that when UpdateManager.flush(..) is called, all instances must be flushed to the datastore. Since you are selectively deciding which StateManagers are going to be flushed, you're not upholding that contract. The reason that you're running into problems is that BrokerImpl drives the calls to the UpdateManager and it expects that all data was flushed and as such, the Broker marks all StateManagers as being flushed. If you want to see where OpenJPA is transitioning the state of your Entities, take a look at BrokerImpl:2220 (trunk). @Search for "mark states as flushed". If you wanted to really dive into OpenJPA, you could potentially also write your own Broker.flush(..) implementation that would do the filtering prior to passing Entities to your UpdateManager. That being said, this would be a rather complicated task. Hope this helps! Thanks, Rick On Thu, Jul 31, 2014 at 2:13 PM, Christoph Weiss <christoph.we...@de.ibm.com > wrote: > Dear Community, > > For our project we added an own UpdateManager for OpenJPA. We use the > UpdateManager to do "explicit updates" for our JPA entities. > This means that we use the UpdateManager to filter the set of JPA objects > and to pass forward only those JPA entities that we want be explicitly > insert or update in the database. > > The UpdateManager is defined in the persistence.xml and working fine: > > <property name="openjpa.jdbc.UpdateManager" value="OurOwnUpdateManager" > /> > > However we have an issue with new JPA entities we create within our use > case / transaction. > The issue: The new entities are created at the beginning and known to the > EntityManager when we create them. > They are in the initial newState with isFlush=false and isPersist = false. > So far so good. > > However when we run a "flush() operation" - e.g. to update the another > objects. The new objects change the state to isPersist and isFlushed. > However no update is happening on the database. > Even if they are not passed from our UpdateManager to the > BatchingConstraintUpdateManager.update(). > > At the end when we pass the objects (e.g. in the third flush operation) > the EntityManager thinks that the objects are already existing and does an > update on the tables instead of the an insert. > And so our application fails. > > Question: > Is there are chance to prevent OpenJPA to set new created objects to > isPersist and isFlushed? > Is it the expected behavior of OpenJPA (meaning that the EntityManager > might change the state of objects during the flush operations that are not > passed to the BatchingConstraintUpdateManager.udpate... ). > Is there a way to reset the state of the objects to tell OpenJPA in one of > the following flushs to do the insert instead of an update? > > Looking forward to any helpful hints, tips and explanations! Thanks in > advance ; ) > > Cheers > Christoph > -- *Rick Curtis*
