There is no explicit life cycle in JPA and I am not suggesting there
should be but there are obvious distinctions to the sort of changes that
are to be synchornized and that have been synchronized and these changes
correspond to EntityManager operations.
--Gordon
Pinaki Poddar wrote:
> Gordon,
> I believe that your usage of "synchronized" is "flushed" in my
> vocabulary. So to address such distinction, consider expanding the
> LifeCycleState enum definition.
>
> Actually this thread perhaps is entering a broader scope:
>
> 1. Does JPA make the persistent life cycle state of entities
> explicit (i.e. appears at API)?
>
> Similar persistence specification (without naming names ;),
> made life cycle states more explicit and their transition rules more
> detailed than where currently JPA stands in this respect.
> The sketch of LifeCycleState enum {NEW, REMOVED, DIRTY,...} etc
> is a nudge in such direction.
>
> 2. Does JPA allow access to managed entities filtered by their life
> cycle states?
>
>
>
> Regards --
>
> Pinaki
>
>
>
>
>
>
>
>
> From: Gordon Yorke <gordon.yorke_at_oracle.com>
> To: jsr338-experts_at_jpa-spec.java.net
> Date: 06/20/11 12:42 PM
> Subject: [jsr338-experts] Re: Standardized Access to ChangeSet
> ------------------------------------------------------------------------
>
>
>
> Within a transaction there are two sets of changes. One set , the
> "unsynchronized" changes, are changes made to the Entities that have
> not yet been synchronized to the database. The other set, the
> "synchronized" changes, are those changes that have been synchronized
> to the database through a flush operation but are not yet committed.
>
> --Gordon
>
> Pinaki Poddar wrote:
> > unsynchronized changes from the synchronized changes
>
> Would you please elaborate "(un)synchronized" as used in this context?
>
> Regards --
>
> Pinaki
>
>
>
>
>
>
>
> From: Gordon Yorke _<gordon.yorke_at_oracle.com>_
> <mailto:gordon.yorke_at_oracle.com>
> To: _jsr338-experts_at_jpa-spec.java.net_
> <mailto:jsr338-experts_at_jpa-spec.java.net>
> Date: 06/20/11 12:09 PM
> Subject: [jsr338-experts] Re: Standardized Access to ChangeSet
> ------------------------------------------------------------------------
>
>
>
> Access to managed entities for any active persistence context is an
> useful feature at any point of time.
> Why would you like to restrict only at flush() via callback?
> By providing the information at flush() time it is easy to define what
> is returned without a plethora of API to distinguish the
> unsynchronized changes from the synchronized changes in the
> transaction. There's little value in combining both sets of changes
> into a single set.
> Also retrieving the list of "dirty" entities could be quite
> "expensive" in some providers or deployment environments but the work
> to calculate the changes will already have been completed during the
> flush() operation.
>
> Based on your example if you are expecting that only the
> unsynchronized changes are available through these sets then these
> APIs along with the EntityManager event would be fine, although I
> would suggest changing the names to reflect the EntityManager
> operations (ie. LifeCycleState.REMOVED).
>
> --Gordon
>
> Pinaki Poddar wrote:
> Hi Gordon/Adam and all,
>
> I should have clarified
> a) the returned Sets be immutable. The elements of the set are live.
> b) returned set reflects the state of the member entities at the time
> of invocation.
> Set<Object> deleted = em.getEntities(LifeCycleState.DELETED); //
> say return a set with 2 entities
> em.remove(another); // another is not a member of deleted set
> assertFalse(deleted.contains(another));
> Set<Object> deleted2 = em.getEntities(LifeCycleState.DELETED);
> assertTrue(deleted.contains(another));
>
> c) Other possibility is to return an Iterator<> instead which is
> always 'live'.
>
> d) the methods return empty set if EntityManager is not in an active
> transaction.
>
> Access to managed entities for any active persistence context is an
> useful feature at any point of time.
> Why would you like to restrict only at flush() via callback?
>
> Regards --
>
>
> Pinaki
>
>
>
>
>
>
>
>
> From: Gordon Yorke _<gordon.yorke_at_oracle.com>_
> <mailto:gordon.yorke_at_oracle.com>
> To: _jsr338-experts_at_jpa-spec.java.net_
> <mailto:jsr338-experts_at_jpa-spec.java.net>
> Date: 06/20/11 11:13 AM
> Subject: [jsr338-experts] Re: Standardized Access to ChangeSet
> ------------------------------------------------------------------------
>
>
>
> Hello Adam,
> Would the "dirty" set include unsynchronized persisted and removed
> Entities? It would likely be better to have separate sets for these.
> Without configuration these sets would have to be cleared as the
> EntityManager is cleared. What effect do you see EntityManager.clear()
> having on these sets?
> As an alternative to the sets an EntityManager lifecycle listener
> could be notified of the sets on EntityManager.flush() and the
> application could track the same sets as need across flushes.
>
> --Gordon
>
>
> Adam Bien wrote:
> > HI All,
> >
> > I would like to propose additional EntityManager methods:
> >
> > Set<Class> updated = EntityManager#getUpdatedEntities(Class<T>.class);
> > Set<Class> deleted = EntityManager#getDeletedEntities(Class<T>.class);
> > Set<Class> created = EntityManager#getCreatedEntities(Class<T>.class);
> > Set<Class> dirty = EntityManager#getDirty(Class<T>.class);
> >
> > We had to use provider-specific EntityManager extensions to access
> the dirty entities for the implementation of replication or historization.
> >
> > Such methods would be also useful for debugging purposes,
> >
> > thanks in advance,
> >
> > adam
> >
> >
> >
>