Own UpdateManager - but issue with "isPersistent" and "isFlushed" for new JPA entities

[Christoph Weiss <ch...@de.ibm.com>]

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 

Re: Own UpdateManager - but issue with "isPersistent" and "isFlushed" for new JPA entities

[Rick Curtis <cu...@gmail.com>]

> 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.weiss@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*