Having a PersistenceContext event listener that included transaction
events would be better.
--Gordon
Pinaki Poddar wrote:
> Hi,
> To complement the current proposal on access to the managed entities
> filtered by their life cycle states (and flush state - which as per
> earlier comment of Michael Bouscher is not strictly a life cycle
> state, and I agree), we could consider a Transaction listener plug-in
> point for the application.
>
> Current listeners are tied to entity life cycle, not transaction.
> In combination, many use cases that are mentioned by Adam Bien and
> others could be addressed, I believe.
>
>
> Regards --
>
> Pinaki Poddar
> Apache OpenJPA Project Chair http://openjpa.apache.org/
> JPA Expert Group Member
> Application & Integration Middleware
>
>
>
>
>
>
>
>
> From: Adam Bien <abien_at_adam-bien.com>
> To: Linda DeMichiel <linda.demichiel_at_oracle.com>
> Cc: jsr338-experts_at_jpa-spec.java.net
> Date: 06/23/11 01:35 AM
> Subject: [jsr338-experts] Re: Standardized Access to ChangeSet
> ------------------------------------------------------------------------
>
>
>
> Hi Linda,
>
> I like Pinaki's proposal now better than my - lets go with his
> suggestion (I'm not sure about the includeSubclasses):
>
> <T> Set<T> getEntities(Class<T> entityType, boolean includeSubclasses,
> LifeCycleState... states);
>
> If hard to implement - we could return "dehydrated" Entites as
> suggested by Emanual.
>
> Top 5 Use Cases:
>
> 1. Implementation of cache synchronization
> 2. Transparent synchronization between RIA apps and serverside EMs
> 3. Auditing
> 4. Versioning / Historization
> 5. Delta Computation for efficient object transfer (similar to 2)
> 6. Debugging / Unit Testing purposes
>
> thanks!,
>
> adam
> On 21.06.2011, at 17:57, Linda DeMichiel wrote:
>
> Hi Adam,
>
> Thanks for raising this issue and your initial proposal. Now that the
> group has iterated over it, I think it would be very helpful if you
> could put together a revised one in terms of what functionality / APIs
> you would like to see added in view of the discussion. I think having
> something very concrete to discuss will help us converge.
>
> thanks,
>
> Linda
>
>
> On 6/21/2011 4:56 AM, Adam Bien wrote:
> HI Gordon,
> On 20.06.2011, at 20:12, Gordon Yorke wrote:
>
> Hello Adam,
> Would the "dirty" set include unsynchronized persisted and removed
> Entities? It would likely be better to have separate sets for these.
>
> Separation would be even better. In the past I just accessed TopLinks
> internals to get this information :-). removed and unsychronized
> entities are also important if you would like to implement a cache
> coordination (like Eclipse Link), or something like Envers.
>
> 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?
>
> IMHO the results should be empty after a clear. But I'm open for any
> suggestions: I never implemented a JPA provider by myself entirely :-)
>
> 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.
>
> EntityListener is also fine - explicit methods, however, are more
> straight forward to use.
>
> --adan
>
>
> --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
>
>
>
>
>
>
>